Methods and systems to manage data objects in a cloud computing environment

ABSTRACT

The present disclosure relates to managing activity taken with respect to cloud-based software services. A platform manages data objects processed by software services and/or those entities that initiate processing events. The platform uses identifiers such as, for example, a persistent identifier (PID) to track processing events. The platform implements rules and/or permissions related to the managed data objects and/or managed entities to determine whettler processing events are in compliance. The platform may update database records, send alerts, send data graphs, or provide a real-time stream related to the managed data objects and/or managed entities. In addition, embodiments involve determining whether a PID-associated managed data object has been modified during processing to generate an additional version of the PID-associated managed data object and, if an object version is present, processing the additional version of the PID-associated managed data object to generate an integrated first PID-associated managed data object.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a utility application that is a continuation of U.S.Pat. Application Titled, “Methods And Systems to Manage Data Objects ina Cloud Computing Environment”, having Ser. No. 17/191,637, filed Mar.3, 2021, which is a continuation of U.S. Pat. Application Titled,“Methods And Systems to Manage Data Objects in a Cloud ComputingEnvironment”, having Ser. No. 16/579,142, filed Sep. 23, 2019, which isa continuation-in-part of U.S. Pat. Application Titled, “Methods AndSystems to Manage Data Objects in a Cloud Computing Environment”, havingSer. No. 16/232,507, filed Dec. 26, 2018, each of which is entirelyincorporated herein by reference.

FIELD OF THE INVENTION

The disclosure relates to methods and systems for managing data objects(e.g., files, calendars, users, groups, devices, hardware, etc.)operational with a plurality of SaaS applications in a cloud computingenvironment. Embodiments of the present disclosure are implemented in acloud computing environment made up of a combination of computerhardware and software. The hardware may include one or more serversconfigured in a distributed environment to provide software services atone or more client devices. Client devices may run instances ofserver-side software applications. Client devices uses these softwareservices to manipulate data objects.

BACKGROUND OF THE INVENTION

Software as a service (“SaaS”) applications are experiencing rapidadoption in today’s corporate environments. Such software solutionsenable collaboration by employees with people both inside and outside oftheir organizations. Moreover, SaaS applications can allow accelerateddeployment of the right software solutions at the right time as neededfor tasks that arise in an organization.

From the employee side, SaaS applications can be the epitome of a “nobrainer.” Employees, especially those who have matured in the era of theevolution of cloud computing over the last 10 or so years, generallycannot fa thorn a world where they do not have access to the bestsoftware tools that are available to them to do their jobs at theprecise time needed. Moreover, in smaller companies, these SaaSapplication-competent employees are often a primary—if not theprimary—driver of software acquisition decisions because, quite simply,smaller organizations will typically be less likely to have a formal ITdepartment that vets and selects software for implementation in thecompany. There also often may not be a corporate infrastructure tomanage use of the software on an ongoing basis, which may mean that thesoftware acquisition process will continue to be SaaSapplications-focused as the company begins to grow. Critically, if thesecompanies scale to a size where a formal IT structure becomesappropriate, the “legacy” SaaS applications may be so embedded withinthe functions of the company that the existing SaaS applicationsecosystem may be carried forward given the likely difficulty ofdisaggregating a myriad of individually deployed software products thathave become central to the operations of the company. Thus, it followsthat, once adopted, SaaS applications can be expected to remain in placein a growing organization, and any issues existing with their use willneed to be addressed at some time during the company’s lifecycle.

Even for mature companies that have implemented formal, embedded ITinfrastructures, SaaS application use likely cannot be avoided in thefuture. As noted, today’s employees expect SaaS applications to beavailable. In organizations that seek to restrict access to SaaSapplications, it can be expected that employees will generatework-arounds to give themselves access to the programs they seek, withthis perception likely being driven by an expectation that “it is easierto ask for forgiveness than to ask for permission.” Such unauthorizedSaaS application-related software, by definition, will not be visible toIT administrators because the users, in fact, intend for them to behidden from management. Accordingly, IT administrators would not be ableto see the actions of users, or “processing events,” with regard to datathat must be managed by an organization. For example, sensitive,regulated, and compliance-related data must be managed to maintain itsvalue and, in many cases, to avoid legal liability. Data that travelsthrough and among these unauthorized—and invisible to management—SaaSapplications, will be difficult, if not impossible, to properly manageunder current computing frameworks. A modern corporate IT policy wouldprefer not allow employees to utilize SaaS applications programs intheir work. There thus currently exists an inherent tension between thelikely behavior of employees and IT administrators in the context ofSaaS application usage.

To further complicate the modern IT department management structure,persons that need access to sensitive or compliance-related data may notbe employed by the organization. For example, consultants, contractors,and freelancers are increasingly engaged to complete company-criticalprojects, even at larger organizations. These non-employee users willoften access sensitive or compliance-related information via SaaSapplications on an as-needed basis, even though corporate IT does notalways have visibility to their operating systems and/or devices. Suchexternal users will then not be directly subject to the organization’spolicies, which makes it even more tenuous for the organization’s ITdepartment to manage data flow proximate to them. It follows that theorganization’s obligations to protect sensitive, regulated, andcompliance-related data may not be appropriately manageable for thesenon-employee users in today’s computing environments.

This lack of visibility can also extend to the employees themselves:organizations are increasingly allowing employees to “bring their owndevices.” This eliminates the often-cumbersome need for employees tocarry multiple devices in which one device is appropriated for businessuse, and the other appropriated for personal use. As opposed toassigning devices to employees to allow IT departments to manage theflow of data through and among that known—and therefore managed—device,IT departments may generally not be given broad access to such personaldevices. Such merging of personal information with business informationon this single device can therefore result in a lesser ability of anorganization to gain access to the device so as to manage corporate datathat travels on or through that device. This is at least because ofemployee privacy issues that may preclude the employer from gainingaccess to personal data, even if for the purpose of managing thevaluable data of the organization. As a result, organizations arefinding it problematic to manage data in the evolving situation whereemployees demand that their employers amend their corporate policies toallow the use of personal devices for the convenience and comfort of theemployee, instead of vice versa.

The evolving SaaS applications IT ecosystem gives rise a new problem ofdata management in an accessible computing environment where access tofunctionalities and data are provided on demand. That is, in the legacyIT world, access to programs, data, etc. was granted from the ITadministrator side of the organization. Employees, devices, and the likewere authorized on a server, database, etc. and policies/permissionswere applied to grant various levels of access or functionalitiesthereto. However, in the SaaS computing environment. this command andcontrol system is not possible because there is typically little if anyinteraction of IT administrators with the underlying SaaS applicationsprogram in that the functionalities generated by the respective SaaSprograms reside at the application level. This can mean that, not onlydoes an IT department possibly not hold knowledge that a particular SaaSprogram is being utilized in corporate operations, IT administrators maynot be able to manage the movement of sensitive, regulated, orcompliance-related data through and among the various programs. Inshort, one cannot manage what cannot be seen, and data that istransferred at the application level may not be visible toadministrators for reasons discussed herein.

Notably, proprietary data holds its value only as long as it remainsconfidential. As such, data breaches involving proprietary data canresult in significant destruction of corporate value. Governmentregulations also set forth strict requirements for disclosure ofregulated data. Indeed, disclosure of some types of data, for example,protected health data, is actionable even if the disclosure wasinadvertent and even if no one actually accessed the data. It followsthat the reduced ability to manage the transfer of managed data in aSaaS application-driven ecosystem does not reduce the obligations of ITdepartments to ensure the protection of such data.

To this end, it is not uncommon today for there to be news reports ofdata breaches in which managed data (e.g., social security numbers,protected health information, personnel records, trade secretinformation, etc.) have been inappropriately disclosed, even innocently.For example, an employee may access an online document signing SaaSprogram. When a document is uploaded to the cloud to generate thee-signature, any information in that document will also be uploaded. Ifthat information is private, sensitive, regulated etc., the act ofuploading the document may constitute a legally actionable data breach.

In yet a further complication that transcends the issues of the evolvingcloud computer IT ecosystem and user devices, there exists theoverriding problem of SaaS application interoperability. In fact, issuesof data and object management in a SaaS computing environment can betraced, at least in part, to issues with the interoperability betweenand among different SaaS applications that are intended to be functionalwith and among each other in a cloud computing environment. As would berecognized, SaaS application functionality is imparted by one or moreAPIs associated with a service or a product. It follows that the codingused to generate each API will underpin the ability of APIs to worktogether to accomplish a user goal. It can be expected that a singleSaaS application vendor will standardize APIs within its own productofferings, at least to ensure that all of the APIs delivered by thatsingle vendor will exhibit interoperability within the vendor’s overallproduct platform. However, standardization among SaaS applicationvendors is not currently the norm. In other words, the SaaS applicationsthat work together in a single cloud computing environment are likely tobe “heterogeneous,” in some respects which, in turn, can lead to somelack of interoperability.

Vendors of platform-level products (e.g., Microsoft, Atlassian, Google,Facebook, etc.) issue documentation for developers creating APIs thatwill be operable with the respective vendor’s offerings. While any APIsdeveloped to run on these platforms will be based on standardprogramming language used for APIs (e.g., Restful APIs, SOAP, etc.),these platforms will typically include proprietary features that caninfluence the coding used to create these applications. This effectivelymeans that differences will exist between SaaS applications developed torun on each of these platforms with the result often being thatinteroperability problems can exist between applications that areintended to be functional with multiple platforms. User operabilityamong various platforms can therefore be comprised.

Many potentially relevant SaaS applications for a cloud computingenvironment may be created by smaller companies, or even individuals, tosolve very specific functionality needs, for example, as a“microservice” to drive a specific hardware product. These products areoften generated from a “Lean Startup” framework. To this end, developersthat are generating new products will create and test individual SaaSapplications that are no more than “Minimum Viable Products” (“MVPs”) todetermine whether a scalable market might exist. As dictated by “LeanStartup” principles, these MVPs are created to be just “good enough” totest a product concept. While the developers may generally adhere todevelopment guidelines and associated coding conventions, the goal ofsuch development is to get a testable product to the market as quicklyas possible. As such, best practices in software development may not bestrictly adhered to, at least at an early stage. Moreover, often thedevelopers of these SaaS products are not professional developers, whichwould make it less likely that generated applications would closelyconform to guidelines for API development. If market testing of aproduct associated with the application is successful, Lean Startupprinciples dictate that the company move ahead quickly to be able tocapture and scale the market opportunity. This means that an applicationwill be built upon, and any features present in the foundational aspectsof the SaaS product will be propagated into the future. While ITadministrators would vet and accept applications in previous generationsof computing infrastructures, it would be apparent that users can beexpected to select a SaaS application based on needed functionality, noton the underlying coding and interoperability thereof with a broadercomputing ecosystem.

Whether due to the variability between the proprietary API developmentguidelines set out for platforms or “bespoke” programming features thatcan be incorporated in a SaaS application, data object structuringresulting from processing of the object in each application can varywithin and among vendors. Such differences may be subtle or marked, butthe mere existence of deviations in data object structuring can greatlyincrease the complexity of managing the operations of SaaS applicationsprograms by an IT department, especially in the context of managing datamovement inside and outside of an organization.

The problem of inconsistencies in the processing of data in and among aplurality of SaaS applications is compounded by the sheer amount ofinformation that must be actively managed in the modern ITinfrastructure. To this end, every SaaS application has a web of dataobjects that reference, interact, control, and/or rely on each other.Examples include, in a nonexclusive listing, users, groups of users,database records (e.g., acquired data, tasks, opportunities, contacts,calendars, chats), mailboxes, files, folders, third-party applications(e.g., that have been installed from app marketplaces and authorized byusers), logs, metadata, permissions, devices, policies, or phone numbers(e.g., numbers assigned to multiple endpoints like mobile applications,IP desk phones, and/or softphones that are included off an interactivevoice response [IVR]/call tree). This web of data objects becomesinherently more complex in multi-SaaS application environments. Forexample, data objects may be connected (or overlap) across applications,but may nonetheless not be aware of each other. This “sprawl” means thatis as yet no single place to view them all, such as in a dashboardformat, for example.

As SaaS application adoption grows, so will the amount of data living inSaaS applications, which in turn creates an enormous, decentralizedinformation sprawl. Where SaaS data lives, and the questions of who hasaccess to it and where it is exposed, become nebulous, even while theneed for managing this data becomes more stringent Thus, a significantissue with SaaS application sprawl is that valuable corporate databecomes scattered across dozens of cloud applications, making itdifficult to find, analyze, and deploy. The owner of the data may notknow what cloud apps retain or have access to its data. This sprawlbecomes amplified when companies have multiple instances of SaaSapplications. For example, many companies have separate accounts ofSlack, Zendesk, and/or Salesforce per department, business unit, oroffice location. The SaaS applications data in these environments can beeven more fragmented because the same data may be distributed within andsiloed across multiple implementations of the same SaaS program in thesame organization.

For example, different departments in a company may generate differentimplementations of Salesforce based on individual needs, preferences,etc. It may follow that interoperability within the same organizationbetween these implementations of the same SaaS program from the samevendor may be compromised as a result. It should be apparent that sincesome or all of the configuration and operation of these individualinstances of a SaaS application (e.g., Salesforce, Slack etc.) are at adepartment level, IT administrators may not be able to ensureinteroperability. Nonetheless, the need to manage data objects operatingin the organization’s cloud computing environment is not reduced.

The amount of operational data that each SaaS application generates canbe overwhelming, as well. In G Suite, for example, an audit log entry iscreated every time a user views, creates, previews, prints, updates,deletes, downloads, or shares Drive content. Similarly, Salesforce’sevent-monitoring API creates event log files for logins, logouts, APIcalls, API executions, report exports, Visualforce page loads, and more.When multiplied by tens, hundreds, or thousands of users, it is apparentthat the amount of information that needs to be managed to ensure thatan organization properly stewards its data can quickly becomeunmanageable. This problem is compounded by the fact that anorganization’s data is continuously being changed, deleted, and added toon a continuous basis, often by many people.

As companies increasingly adopt SaaS applications, critical informationis located across a number of distinct sources rather than storedlocally on physical endpoints such as users’ devices and on-premisesservers, There is no consistency across SaaS applications. In multi-SaaSenvironments, settings are adjusted in different places (e.g., an adminconsole vs. a Team Settings page). Each application has its own “datasilo,” even while data overlaps. For instance, Drive and Dropbox filescan be shared in Slack. Depending on the environment. a user may be ableto install as many third-party applications (e.g., Chrome extensions,bots, or marketplace applications) as he would like. Many of these SaaSapplications work together in some way, and all it takes is oneseemingly innocuous application integration to constitute avalue-destroying data breach. Data objects all have differentnomenclatures (e.g., a “group” vs, a “channel”). There is no singleunified view or administrative vocabulary across SaaS applications forIT professionals. Not only does this mean IT departments must visitmultiple disparate administrative consoles (e.g., dashboards) to carryout administrative tasks, but it also means they have no global view oftheir overall computing environment. Ultimately, this type of SaaSsprawl means IT has little to no control over what enters theenvironment. Without the ability to manage data flow among a pluralityof SaaS applications, or to centralize and view its organization’s data,IT departments lack effective oversight. This impairs the capacity tounderstand what’s even happening in the environment.

It follows that the shift to SaaS applications requires new frameworksand tools to allow IT professionals to manage, secure, and supportapplications that are critical to the operation of their organizations.However, currently, there exists no structured way to manage enterpriseSaaS applications, nor are there tools and techniques that canfacilitate IT professionals’ achieving their security goals andrequirements with respect to data moving in and among various users,programs, and devices in cloud computing environments. In short, thereremains a need for improvements in the ability to manage data objects ina computing environment that comprises a plurality of SaaS applications.The present disclosure provides these, and other, benefits.

SUMMARY OF THE INVENTION

The present disclosure is directed to a management platform that managesentities (e.g., a user, user groups, etc.) who use heterogeneoussoftware services (e.g., SaaS applications) to process data objectswithin a cloud computing environment. The management platform alsomanages those data objects. These managed data objects are independentlyassociated with the managed entities. The managed entities each have anentity identification. The managed data objects or managed entities areeach independently associated with one or more permissions. Thesepermissions may be defined by a manager responsible for managed dataobjects or managed entities. Permissions are associated with rulesdefinable for the managed data objects or identified managed entity. Therules may also be defined for one or more processing events performableon the managed data objects. A processing event may be, for example,accessing (e.g., downloading), creating, viewing, merging, altering,sharing, sending, copying, printing, deleting, modifying of the manageddata objects, or any combination or sequence of these actions performedon the managed data objects.

The management platform receives information about the one or moreprocessing events. This may involve extracting API information receivedfrom different application serves used by the managed entities. Themanagement platform determines whether the managed data objects isindependently associated with a persistent identifier (PID) and, if anyof the managed data objects is not associated with a PID, generating aPID for each non-PID-associated managed data object. This provides themanaged data objects such that they are each is independently associatedwith a PID. The management platform generates an information set (e.g.,data graph, real-time data stream) that identifies the processing eventsperformed on each of the PID-associated managed data objects in thecloud computing environment. This provides status information for thestate of the processing events to managers, IT admins, or otheroperators. The management platform also compares each of the processingevents with rules and generates information about whether the processingevents performed on one or more of the PID associated managed dataobjects is out of compliance with one or more of each of the associatedrules. This may lead to the transmission of an alert to a manager.

Embodiments of the present disclosure are also directed to managing dataintegration as one or more SaaS Applications process data objects. Theprocessing of a data object creates various versions of the same dataobject, thereby creating a need for version control. To address this,systems and methods are directed to determining whether the firstPID-associated managed data object has been modified during processing.If so, the systems and methods may generate one or more additionalversions of the first PID-associated managed data object The presence ofone or more additional object versions may trigger a processing of eachof the additional versions to generate an integrated PID-associatedmanaged data object.

Additional advantages of the present disclosure will be set forth inpart in the description that follows, and in part will be apparent fromthe description, or may be learned by practice of the presentdisclosure. The advantages of the present disclosure will be realizedand attained by means of the elements and combination particularlypointed out in the appended claims. It is to be understood that both theforegoing general description and the following detailed description areexemplary and explanatory only and are not restrictive of the presentdisclosure, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a drawing of a computing environment, according to variousembodiments of the present disclosure.

FIGS. 2A-D represent examples of portions of the functionality of amanagement application executed in a computing environment of FIG. 1 .according to various embodiments of the present disclosure.

FIG. 3 depicts an example of how a management application manages anentity that uses the services provided by a plurality of providercomputing systems, according to various embodiments of the presentdisclosure.

FIG. 4 provides an example of the functionality of the managementapplication as an improvement over prior solutions.

FIG. 5 is a flowchart that provides an example of the operation of themanagement application according to various embodiments of the presentdisclosure.

FIG. 6 shows a schematic block diagram of the management platform ofFIG. 1 , according to an embodiment of the present disclosure.

FIG. 7 shows an example of managing data integration in the computingenvironment, according to various embodiments of the present disclosure.

DETAILED DESCRIPTION OF THE INVENTION

The descriptions of the various embodiments of the present disclosurehave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

The term “substantially” is meant to permit deviations from thedescriptive term that do not negatively impact the intended purpose. Alldescriptive terms used herein are implicitly understood to be modifiedby the word “substantially,” even if the descriptive term is notexplicitly modified by the word “substantially.”

While this disclosure provides a description of the specificimplementation of cloud computing, it should be appreciated that thedescription herein is not limited to a cloud computing environment.Rather, aspects of the present disclosure are suitable for use with anyother type of computing environment now known or later developed.

As would be recognized, “cloud computing” is a model of service deliveryfor enabling convenient, on-demand network access to a shared pool ofconfigurable computing resources. In non-limiting examples, suchcomputing resources can include one or more of: networks, networkbandwidth, servers, processing, memory, storage, applications, virtualmachines (VMs), and services.

A cloud computing environment is characterized by a number of features.First, a cloud services user can unilaterally provision computingcapabilities, such as server time and network storage, as needed andautomatically, that is, without requiring human interaction with theprovider of the service being provisioned. The user can also access anetwork broadly, in that capabilities are available over one or morenetworks and can be accessed via varied and standard client platforms ordevices (e.g., mobile phones, laptops, and PDAs, etc.). In a furthercharacteristic, a service provider’s computing resources will be pooledto serve multiple users in a multi-tenant model. This enables differentphysical and virtual resources at the provider level to be dynamicallyassigned and to be assigned according to user demand. Locationindependence is present in relation to a user’s general lack of controlor knowledge over the exact origin or location of the providedresources, however, a user may be able to specify location at some levelof abstraction (e.g., country, state, or data center). Further, serviceprovider capabilities can be rapidly and elastically and, in some cases,automatically, provisioned. From the user perspective, the provider’scapabilities available for provisioning often appear to be unlimited andcan be purchased in any quantity at any time. Cloud computingenvironments also allow automatic control and resource optimization byenabling metering capabilities in a context appropriate to the type ofservice (e.g., storage, processing, bandwidth, and active consumeraccounts). Resource usage can therefore be monitored, controlled, andreported, thereby providing transparency for both the provider andconsumer of the utilized service.

Cloud computing environments are associated with various categories ofservice, namely, Software as a Service (“SaaS”), Platform as a Service(“PaaS”), Infrastructure as a Service (“IaaS”), and Integration platformas a service “(iPaaS”). Each of these is discussed below.

-   . Software as a Service (“SaaS”): the ability to utilize provider    applications running on a cloud infrastructure. The applications are    accessible from various client devices through a thin client    interface, such as a web browser (e.g., web-based email). The    consumer does not manage or control the underlying cloud    infrastructure including network, servers, operating systems,    storage, or even individual application capabilities, with the    possible exception of limited consumer-specific application    configuration settings.-   · Platform as a Service (“PaaS”): the capability provided to the    consumer is the ability to deploy onto the cloud infrastructure    consumer-created or acquired applications created using programming    languages and tools supported by the provider. The consumer does not    manage or control the underlying cloud infrastructure including    networks, servers, operating systems, or storage, but has control    over the deployed applications and possibly application-hosting    environment configurations.-   · Infrastructure as a Service (“IaaS”): the capability provided to    the consumer is the ability to provision processing, storage,    networks, and other fundamental computing resources where the    consumer is able to deploy and run arbitrary software, which can    include operating systems and applications. The consumer does not    manage or control the underlying cloud infrastructure but has    control over operating systems, storage, deployed applications, and    possibly limited control of select networking components (e.g., host    firewalls).-   · Integration platform as a service (“iPaaS”) is a platform for    building and deploying integrations within the cloud and between the    cloud and enterprise. With iPaaS, users can develop integration    flows that connect applications and/or data residing in the cloud or    on-premises and then deploy them without installing or managing any    hardware or middleware. In the context of data, and in accordance    with the disclosure herein, iPaaS can enhance the ability to process    managed data objects within SaaS applications operating in a cloud    computing environment.

Deployment Models are as follows:

-   · Private cloud: the cloud infrastructure is operated solely for an    organization. It may be managed by the organization or a third party    and may exist on-premises or off-premises.-   · Community cloud: the cloud infrastructure is shared by several    organizations and supports a specific community that has shared    concerns (e.g., mission, security requirements, policy, and    compliance considerations). It may be managed by the organizations    or a third party and may exist on-premises or off-premises.-   · Public cloud: the cloud infrastructure is made available to the    general public or a large industry group and is owned by an    organization selling cloud services.-   · Hybrid cloud: the cloud infrastructure is a composition of two or    more clouds (e.g., private, community, or public) that remain unique    entities but are bound together by standardized or proprietary    technology that enables data and application portability (e.g.,    cloud bursting for load balancing between clouds).

In a first aspect, the present disclosure comprises a method of managingdata objects comprising managing, in a cloud computing environment, aplurality of managed data objects. The cloud computing environment cancomprise a plurality of SaaS applications, wherein at least two of theplurality of applications are heterogeneous, as such term is definedelsewhere herein. Each of the plurality of managed data objects areeach, independently, correlated with one or more managed entities, assuch term is defined elsewhere herein. Each managed entity has an entityidentification, thereby providing a plurality of managed data objectsassociated with an identified managed entity. Either or both of theplurality of managed data objects or managed entities are each,independently, associated with one or more permissions definable by amanager of each of the plurality of managed data objects or each of themanaged entities. The permissions are associated with one or more rulesdefinable for either or both of the managed data objects or identifiedmanaged entity; and one or more processing events performable on themanaged data objects by the identified managed entity or one moreactors. In accordance with the present disclosure, at least some of theprocessing comprises the one or more processing events, wherein the oneor more processing events comprises one or more of accessing (e.g.,downloading), creating, viewing, merging, altering, sharing, sending,copying, printing, deleting, or modifying of the managed data objects,as discussed further hereinafter. The present disclosure furthercomprises receiving, by the computer, information about the one or moreprocessing events, and determining, by the computer, whether each of themanaged data objects is, independently, associated with a persistentidentifier (PID) and, if any of the managed data objects are notassociated with a PID, generating a PID for each non-PID- associatedmanaged data object, thereby providing a plurality of managed dataobjects wherein each is independently associated with a PID. This PIDaspect of the present disclosure is further described hereinafter. Aninformation set identifying each of the one or more processing eventsperformed on each of the PID-associated managed data objects in thecloud computing environment can be generated, which can allow real time(e.g., current or substantially current) information for the state ofthe processing events performed by the one or more actors on thePID-associated managed data objects in the cloud computing environmentto be obtained. Once this information set is obtained, a comparison stepis generated wherein each of the processing events performed by the oneor more actors on the PID-associated managed data objects with one ormore of the permissions associated with either or both of the manageddata objects or the one or more identified managed entities. As a resultof this comparison step, information can be generated about whether theone or more processing events performed on one or more of thePID-associated managed data objects is out-of-compliance with one ormore of each of the associated permissions. In addition to generatinginformation, the information is transmitted as a notification thatindicates the non-compliance.

As used herein, data objects that can be managed, and that can conformto the definition of “managed data objects,” is expansive and caninclude, in a nonexclusive listing: comprise at least one of: users,groups, mailboxes, files, folders, calendar events, contacts, contactinformation, database records, metadata, permissions, chats, messages,emails, data streams, hardware devices (e.g., desktop computers,smartphones, tablet computing devices, electronic book (e-book) readers,netbook computers, notebook computers, laptop computers, personaldigital assistants (PDA)), vehicles, policies, phone numbers (e.g.,numbers assigned to multiple endpoints like mobile applications, IP deskphones, and/or softphones that are included off an interactive voiceresponse [IR/call tree} etc.), IP addresses, cloud computing projects,collaboration projects, and unique object/device identifiers. Infurther, nonlimiting examples, the managed data objects can include oneor more of entry fobs/cards, cloud hosting projects (e.g., Amazon EC2projects, Google Cloud Platform projects, etc.), social media posts onan organization’s behalf, third-party applications that have beeninstalled from app marketplaces and authorized by users, policies, logs,permissions, computing devices (smartphones, web-enabled televisions,video game consoles, set top boxes (STB), digital video recorder (DVR)systems, wearable user devices etc.), sensors or collection ofmechanical or environmental sensors (e.g., thermometers, pressuresensors, vibration sensors, odometers, accelerometers, ammeters,voltmeters, power meters, GPS locators etc.), vehicles (e.g.,automobiles, trucks, planes, drones, e-scooters, bicycles, etc.),medical devices or instrumentation, machines or equipment (e.g., HVACsystems, refrigeration equipment, appliances, elevators/escalators,etc.), among other things, As would be appreciated, the managed dataobject can also comprise devices, sensors, or any type of electroniccomponentry (collectively “device componentry”) that are networked in adynamic “Internet of Things,” (“IoT”) wherein each of the networkeddevice componentry are, independently, associated with at least one SaaSapplication that is in operational engagement with a cloud computingsystem in a networked environment.

In significant aspects, the data objects are “managed,” in that there isa desire or obligation by an owner, manager, and/or regulator to trackand, in some aspects, to be able to audit actions taken on each of themanaged data objects in the cloud computing environment and by whom orwhat such actions were taken. In some aspects, the managed data objectscomprise, includes, or is associated with at least some regulated,sensitive or compliance-related information, that is, information thatis: 1) proprietary such that it the generates one or more competitiveadvantages for the owner as long as it is kept confidential or access isrestricted or that should otherwise be kept secret/unavailable tocompetitors or the public; 2) that is subject to legal restrictions asto access or distribution as defined by one or more laws and/orregulations (e.g., Healthcare Information Privacy and Portability Act“HIPPA,” Sarbanes Oxley, state and federal privacy laws, bankingregulations, Uniform Trade Secrets Act “UTSA”, Defend Trade Secrets Act“DTSA,” General Data Protection Regulation “GDPR,” etc.); 3) that issubject to a legal obligation to maintain confidential as set out in acontract, agreement or the like; 4) for which it is otherwise desirableto limit access to the information therein (e.g., personal information)at least because consumers may not appreciate that third parties maygain access to their information may release it to third parties withouttheir express approval, even when they have given access to a firstparty to such information.

A “managed entity” can be anything that has or can have access to amanaged data object. In short, it can be anything that a manager (whichcan be a human or a computer or both) has the ability to track, control,etc. their actions in a cloud computing environment, such as to directlygrant or revoke access to managed data objects, programs, systems, etc.A “managed entity” can be, for example, an employee or a group ofemployees (e.g., a department), or a group of users that can be managedby an administrator (e.g., shared membership in a controlled accessenvironment). Still further, a “managed entity” can comprise a hardwaredevice (e.g., computer, smartphone, IoT device), vehicle, accesscard/fob, among other things.

An “actor” can include anyone or anything that, in the cloud computingenvironment, may perform various processing events on, or be involved invarious processing events, that may of interest. For example, processingevents that allow third parties to gain access to a managed data objectwould be of interest for tracking, monitoring, auditing etc. if thatmanaged data object is subject to regulation, or is proprietary,sensitive or compliance-related. In some aspects, the actor can bemanaged entity, such as when a person who shares a managed data objectis an employee of a company that owns or is responsible for the manageddata object. Access to the managed data object can be deprovisioned byremoving a permission to access the managed data object by anadministrator when the actor is a managed entity. However, in someaspects, the actor can be a third party to whom the administrator has nodirect ability to control access to the managed data object, such aswhen the third party is someone with whom an employee shares the manageddata object, and the third party is not an employee or otherwise underadministrative control of the company. for example. Other possiblescenarios are detailed hereinafter.

In a significant aspect, the methods herein can address the technicalproblem of monitoring, tracking, managing, auditing etc. the processingof managed data objects in and among a plurality of SaaS applications ina cloud computing environment, wherein at least two of the applicationsare heterogeneous. As used herein. “heterogeneous” means differentapplications that are produced, created, developed etc. by differentproviders/vendors, different application instances from the sameproviders/vendors, and/or that are further customized applicationinstances of the same provider/vendors. For example, Google andSalesforce are “heterogeneous” SaaS applications because they are fromdifferent providers/vendors. However. Two Salesforce implementationswithin a single company but in different departments can also be“heterogeneous” because they may incorporate customizations for eachrespective department As discussed previously, the flexibility providedby SaaS applications, and the attendant loss of IT administrator controlof implementation within or among organizations can frequently give riseto the inability of the administrative functions to readily manage IT inthe cloud computing environment. In one aspect, “heterogeneous” means atthat there exists at least the possibility that at least one SaaSapplication operational in a cloud computing environment is functionallycapable of decorrelating a managed data object from a managed entityprior to the association of that managed data object with a PID, as isdiscussed in more detail hereinafter.

An organization that implements the systems and methods of the presentdisclosure can. in significant aspects, incorporate an almost unlimitedvariety of SaaS applications within a network computing environmentsubstantially without reducing or eliminating the ability track the flowof and use of managed data objects between and among such applicationsby both internal and external users, devices, etc.

In some implementations, a managed data object can also be a managedentity, depending on context. For example, a medical device canincorporate protected health information thereon. In some contexts, themedical device is a managed entity and the protected health informationis the managed data object. In other contexts, the medical device itselfcan be the managed data object, and the managed entity can be a personwho is responsible for managing the medical device, such as an employee.A key fob granting entry to a location can be a managed entity and thedata associated with such entry can be the managed data object, or thekey fob can be the managed data object, and the managed data entity canbe the person who is responsible for the managed data object.

A variety of processing events are potentially relevant to tracking themanaged data objects in the cloud computing environment. These caninclude, for example, accessing, creating, viewing, merging, altering,sharing, sending, copying, printing, deleting, or modifying the manageddata objects. Permissions and rules associated with the managed dataobjects and/or managed entities can be generated, as is set out in moredetail hereinafter.

“Suspicious” processing events can also be tracked, monitored, audited,etc. As used herein, “suspicious events” include, in non-limitingexamples, events relating to managed data objects, for example dataobjects that have been deemed as being of interest. In this regard, thepresent disclosure can comprise selecting for tracking one or moremanaged data objects and one or more events associated with that manageddata object, and tracking that selected managed data object(s) and theselected event(s) performed on that managed data object(s) in the cloudcomputing environment In nonlimiting examples, the following can betracked for the selected managed data object(s) in the cloud computingenvironment: downloading, file sharing, mass file sharing, mass filedownloading, email forwarding, account transferring, delegation accessgranted, file downloading, file sharing, mass file sharing, mass filedownloading, email forwarding, account transferring, delegation accessgranted, consecutive login failures, logging in from multiple locations,logging in from a suspicious location, accessing files from suspicious(e.g., unknown, unauthorized, etc.) locations, downloading files from asuspicious locations, group access settings changed, user permissionschanged, 2 factor disabled, admin downgraded, admin deleted, grantingapplication/token access, connecting mobile devices, devicescompromised, and lost devices, among other things.

Such tracking, monitoring, auditing, etc. is possible even though one ormore of the SaaS applications operational in the cloud computingenvironment may include programming features that operationally mayremove, modify, delete, or otherwise transform the correlation betweenthe managed entity and the managed data object during processingthereof. For example, a SaaS application may remove a correlationbetween a managed entity who is an employee and a file that is a manageddata object when that file is processed by the first SaaS application.When information about that processing event and file are received, theabsence of the expected correlation can reduce the ability of a systemto track, monitor, audit, etc. the processing events performed on thatfile in the cloud computing environment. In this regard, the presence ofat least one heterogeneous SaaS application in the cloud computingenvironment can give rise to a reduced ability to automatically analyzeprocessing events performed on the managed data objects, at leastbecause, after processing, a managed data object may no longerincorporate expected identity information.

During processing of a managed data object to provide the desired userfunctionality with which that managed data object is associated, one ormore of a plurality of SaaS applications operating in the networkcomputing environment may, at the level of each respective SaaSapplication, independently, modify, remove, or replace the correlationbetween a managed data object and a managed entity to result inde-correlation thereof. For example, if the managed data object wascorrelated with the managed entity johnmsmith@smithco.com when themanaged data object was created, and during operations in SaaSapplications, the managed data object correlation is removed, modified,or replaced by an application, the managed data object will no longerpossess the assigned managed data object entity correlationcharacteristics. It may then become difficult, if not impossible, for anIT administrator, such as via a network computing module that processesthe managed data object, to accurately monitor, track, manage, auditetc. actions that were taken on that managed data object among aplurality of SaaS applications in a network computing environment.

Modification, removal, or replacement of the correlated, or expected,managed data object identification can result from the specificoperational aspects of a SaaS application operating in the cloudcomputing environment. As discussed previously, no standardization ofAPI configurations exists. While recommendations exist as to how togenerate APIs exist within various operational frameworks (RESTful, SOAPetc.), variations in programming can exist even within these frameworks.Indeed, considerable latitude is usually given to developers whengenerating a desired functionality using programming language. Moreover,many SaaS applications today may be formulated in a “quick and dirty”fashion in which an API is not generated with a goal to enhanceinteroperability with other SaaS applications but, rather, are initiallyintended as a stand-alone product with a specifically defined or specialpurpose functionality. When such a SaaS application is later integratedwith other applications to generate a plurality of SaaS applicationsoperational together in a network computing environment, these one ormore applications may modify, remove, or replace the association betweena managed data object and managed entity.

The increasing “sprawl” associated with SaaS applications alsocontributes to the likelihood of different identities being ascribed toa single managed data object, at least because as more APIs becomeoperational with the same managed data object, the more likely it isthat the managed data object correlations may begin to deviate from anassigned/expected value at some time during the lifecycle of the manageddata object in a cloud computing environment. Such deviation can reduce,or even prevent, the ability for an IT administrator to automaticallymonitor, manage audit etc. actions taken at the SaaS applications levelfor that same managed data object since the same managed data object canbe associated with two or more managed data object identifiers afterprocessing thereof in the cloud computing environment.

In an implementation, the systems and methods herein pertain to themonitoring, tracking, managing, auditing etc. of one or more manageddata objects that is or has been in operational engagement with aplurality of SaaS applications, that is, subject to one or moreprocessing events. Notification of such operational engagement isindicated by receiving of information pertaining to one or moreprocessing events. As would be appreciated, such received informationrepresents specific actions or operations that a SaaS application caninvoke at runtime to perform tasks, for example: in relation to dataquerying, accessing, adding, modifying, updating, deleting, modifying,sharing, printing, etc. Logins, adding of users or groups, acquiringSaaS applications, and other events can also be associated with receivedprocessing event information. The processing event information may beassociated with a web-based system, an operating system, a databasesystem, computer hardware, device hardware, or a software library.

As would be appreciated, SaaS applications can leverage existing manageddata objects owned or managed by a party—such as a company that creates,owns, administers, manages etc. the managed data object—to providefunctionality that is demanded by users. Increasingly, SaaS applicationsare generated to provide limited and self-contained functionality thatcan be combined with other SaaS applications on an as-needed basis toallow users to define and orchestrate their own experiences, as opposedto having to purchase software platforms that may provide comprehensive“one size fits all” functionality.

In this regard, the present disclosure incorporates functionality thatenables interoperability between such plurality of SaaS applications bysubstantially ensuring that a single managed data object correlationwith a managed entity will be maintained in a persistent fashionindependently of how the managed data object may be processed in thecloud computing environment. In particular, the methodology herein isconfigurable to determine whether a managed data object processed in acloud computing environment has been assigned a persistent identity. Ifa persistent identity is found not to be associated with the manageddata object, processing can allow the identity of the managed to bedetermined, such as by processing of one or more of the data objectmetadata, SaaS application metadata or the managed data objects.

In one aspect, the present disclosure allows the normalization ofmanaged data object identities and correlation thereof with one or moremanaged entities across a plurality of SaaS applications to enhanceinteroperability of the plurality of data SaaS applications in relationto managed data objects moving in and among those applications. The typeof SaaS applications in the plurality of applications can be highlyvaried. “Interoperability” can be defined as a measure of the degree towhich diverse systems or components can work together successfully. Amore formal framework is the ability of two or more systems orapplications to exchange information and mutually use the informationthat has been exchanged. “Syntactic interoperability” relies onspecified data formats, communication protocols, and the like to ensurecommunication and data exchange between at least two systems, be theyplatforms, devices, programs, files, or the like (collectively“systems”). For syntactic interoperability, the exchanged informationcan be processed, but there is no guarantee that the interpretation isthe same. “Semantic interoperability,” on the other hand, exists whenthe at least two systems have the ability to automatically interpretexchanged information meaningfully and accurately in order to produceuseful results via deference to a common information exchange referencemodel. The content of the information exchange requests is unambiguouslydefined: what is sent is the same as what is understood.

To this end, and as would be appreciated, between and among a pluralityof SaaS application a single managed data object may be processed invaried manners to result in the generation of a plurality of connectedmanaged data objects. To illustrate: files stored in file storageservices can differ from those in chat applications, which can differfrom those in CRM applications. The same managed data can be stored indifferent places when functional within a plurality of SaaSapplications, and each application can have its own set of APIs foraccessing that data programmatically. Each application can havedifferent access, permissions, and sharing models as well. Thus, for anIT department to be able successfully manage data objects within anorganization’s cloud computing environment, the plurality of connectedmanaged data objects (e.g., audit logs, calendars, files, metadata,groups, users (including external users, tickets etc.)), must beingested and normalized across a plurality SaaS applications, some orall of which may be heterogeneous.

In use, a managed data object identification may be modified, removed,or replaced in conjunction with a processing event for many reasons, oreven for no reason. In a SaaS application environment such actions areoperational at the level of each SaaS applications. As such, any actionson the managed data object will typically be outside of the ability ofthe managed data object owner or manager’s ability to control. This isin contrast to the situation that existed in the past, where acentralized point of administration existed for network computingenvironments. In many situations in today’s cloud computingenvironments, the actions made on managed data objects therefore willnot be visible to the data owner or manager in real time, or even at allat least because there is no centralized point of control.

When processing event information is received by a network computingmodule with a report that the managed data object was subjected to aprocessing event in conjunction with a SaaS application, the module canbe operational to determine whether there is a persistent identifier(“PID”) associated with the managed data object. If there is no PIDassociated with the managed data object, one can be assigned. Once madepersistent, the managed data object having an associated PID will remainconsistently identifiable in subsequent SaaS applications operations. An“expected value” for a managed data object identity can vary accordingto the implementation, where an expected value is an identifier that haspreviously been assigned to the managed data object or has otherwisebeen matched to or associated with the managed data object. Innon-limiting examples, an expected value can comprise an email address,owner’s name, employee ID number, social security number, telephonenumber, barcode, QR code, IP address, device ID, or the like.

By association of a PID to a managed data object, a standardized andunmodifiable data object identity can be associated with each manageddata object The PID will therefore remain the same even though a SaaSapplication may, in a future processing event, modify, remove etc. theentity identification for that managed data object The PID can beincorporated in metadata associated with the managed data object. Tothis end, the managed data object is assigned a PID that will remain thesame regardless of where the managed data object is located, how it isprocessed, or how it is stored. The association of a PID to a manageddata object thus facilitates the ability to keep track of processingevents performed on the managed data object. The association of a PIDtherefore provides the capability to unambiguously identify such manageddata objects irrespective of the actions taken thereon by remotelyoperated SaaS applications. Such PIDs can be maintained through thelifecycle of a respective managed data object to allow the object to beidentified consistently and permanently.

In further aspects, a network computing module is configurable toprocess a managed data object having a data object identity that doesnot conform to an expected value by evaluating information associatedtherewith, such as metadata. For example, if an expected value for adata object identity is an email address, such asjohnmsmith@smithco.com, and a data object’s metadata after processing ina SaaS application does not incorporate such an email address (e.g., theemail address was modified, removed, or replaced by the application),the managed data object will not have an expected data object identity.In such a case, the managed data object can be processed to extract orotherwise provide information that can be used to substantially, andaccurately assign an identity to that managed data object, followed bygeneration of a PID for that managed data object.

For example, if a data object identity does not conform to thejohnmsmith@smithco.com expected data object identity, the networkcomputing module can process the object’s metadata, SaaS applicationmetadata, and the managed data objects themselves to generate anaccurate identification of the managed data object so as toappropriately associate the managed data object with a managed entity.As a nonlimiting example, the managed data object metadata may includesome form of identifier such as one or more of a user’s name,personally-identifiable information that !inks the managed data objectto a managed entity (e.g., Social Security number, unique useridentification number, payment card information, phone number, or thelike), location (home address, GPS coordinates etc.) or otherinformation that can be reliably inferred to enable a matching of themanaged data object with a managed entity that is, or should becorrelated, to that object (e.g., person, group, organization etc.) orany other unique identifying information that can be used to correlate amanaged entity to that managed data object A managed entity can be“associated” with a managed data object via a record of actions takenthereon by the managed entity where the record is obtainable for use.For example, the managed entity could have created, accessed, viewed,printed, modified, shares, etc. the data object in conjunction with theentity’s roles and responsibilities in the organization. Informationabout such association can be generated, at least in part, from the dataobject of interest’s metadata. For example, if “Bob” is an employee ofan organization, and Bob creates, accesses, views, prints, modifies,shares, etc. a data object that is managed by the organization (e.g.,the data object comprises sensitive, regulated, or compliance-relatedmaterial), the data object’s metadata will incorporate information thatassociates Bob with the managed data object. Subsequent programmingevents performed on that managed data object, either by “Bob” as themanaged entity or by a third-party actor who is not a managed entity,can then be monitored, tracked, audited, etc. according to thedisclosure herein.

While the PID can allow a managed data object to be durably associatedwith the managed entity for use in subsequent processing events, in someaspects, a second, or global identity, can be assigned to thePID-associated managed data object. For example, if “bob@smithco.com” isthe PID-association generated after processing of the managed dataobject, a separate identification can be assigned to the PID-associatedmanaged data object such as “confirmed identity = bob employee atsmithco, id# 12345.” Such a “global identity” can allow confirmation foran administrator that the identity of the managed data object has, infact, been processed to generate an actual, and correct, associationwith the managed entity. In other words, the “global identity” can serveas validation that the processing according to the present disclosurehas been conducted, and that information generated about such processinga cloud computing environment is accurate.

The step of correlating a managed data object with a managed entity canoptionally provide a probability that the managed data object has beenaccurately identified and correlated. If the probability is below acertain level, for example, below about 0.99 or below about 0.95, orbelow about 0.90, an indication and optional notification can begenerated that an inaccurate managed data object/managed entitycorrelation may have been generated. In such a case, a report etc. canbe generated to allow monitoring, managing, auditing etc. of potentiallyinaccurate correlation of managed data objects with managed entities.For example, a probability that the generated global identity is correct(or incorrect) can be provided. Still further, a human operator can beprompted to review such potentially inaccurate generated managed dataobject/managed entity correlations for correction thereof or othersuitable operations that can be affected on such managed data objects.In some aspects, machine learning and training sets can be incorporatedto improve the operation of the managed data object identitynormalization step over time.

When a processing event (e.g., accessing, sharing, copying, printing,modification, etc.) is performed on a managed data object by a SaaSapplication, such action will be visible after the fact via receivedinformation about such events. Such processing events can be comparedwith one or more rules associated with the managed data object and/orthe managed entity to determine whether the processing event performedon that managed data object is compliant with the one or more rulesassociated with that object. In accordance with the improvements inconfirming each managed data object identity and by making eachpersistent, an IT administrator can be sure that the reports on manageddata objects are complete and correct.

To this end, the manager of a managed data object and/or a managedentity—that is, an IT administrator or an IT department of anorganization or among a collection of users etc. —will often beinterested in or legally required to monitor, track, audit etc.processing events performed on a managed data object and/or that wereperformed by the managed entity, and that might be taken in the future.Such processing events can be associated with rules that govern or areassociated with the managed data objects and/or the managed entity. Ifsuch processing events are shown to be out-of-compliance with one ormore rules, information can be generated therefore. Such information canbe provided via a notification to one or more of the managed, the actor,the system administrator, or a database record.

In accordance with the rules associated with the managed data objectsand/or the managed entities, the present disclosure further comprisescomparing a processing event performed on a managed data object having aPID associated therewith to determine whether the event complies withone or more rules associated with that managed data object and/or themanaged entity. A rule can be specifically defined for the managed dataobject, the managed entity or the rule can be defined for a user orgroup of users, or otherwise. Rules can be generated by the organizationinternally, or by an external standards organization, or by agovernmental agency via regulation.

Such rules can be fully or partially generated at the network level. Forexample, a user or a manager of the network can actively define and setrules from a dashboard or the like. Alternatively, a rules engine canapply rules that have been defined. In this regard, instead of beingpresented to a manager for action thereon, the rules can beautomatically defined and managed data object and/or managed entityactions at the SaaS applications level can be automatically processed toassess compliance with one or more rules and, optionally, for actionthereon. Such automated compliance modules are an emerging businessmodel in the cloud computing ecosystem and are generally referred to a“compliance as a service” (“CaaS”). One example of a methodology thatcan be used in a CaaS implementation is disclosed in U.S. Pat.Publication No. US20160080422, the disclosure of which is incorporatedherein in its entirety.

Any processing events performed on managed data objects (e.g., sharing,editing, copying, printing etc.) or by managed entities that arereported to the system could be determined to be out-of-compliance witha defined rule. If such non-compliant events are indicated to haveoccurred by comparison of the event with a defined rule for that manageddata object (or class/type of managed data object) and/or managed entity(or class/type of managed entity), an out-of-compliance notification canautomatically be generated. In some aspects, an out-of-compliancenotification may be processed automatically to generate a notificationto a managed data object owner/manager, the managed entity, athird-party actor, or for storing in a database record, such as for usein a developing an audit trail. Still further, such automated processingmany not generate a notification. Such automatic notifications (orabsence thereof) can be generated (or not generated) in accordance withexisting management of and/or filtering of notifications as described inU.S. Pat. Nos. 9348687 and 9521035, for example, the disclosures ofwhich are incorporated herein in their entireties by this reference.

In accordance with a compliance module, a managed data object and/or amanaged entity can have a rule associated with the type or class ofmanaged data object and/or managed entity. For example, a managed dataobject can be classified as “proprietary,” such as would be appropriatefor trade secret or confidential information. Such information may besubject to one or more rules that are intended restrict access to thatinformation to persons in and among an organization, where such personsmay be associated with a particular department, position, or the like.In some circumstances, such proprietary information may be accessible topersons external to the organization, such as freelancers, consultants,contractors, or service providers. If processing event information isreceived about a managed data object (e.g., accessing, sharing, copying,modifying, printing, etc.), such processing event can be compared to arule that is associated with that specific managed data object, type ofobject, or data object classification to determine whether thatprocessing event is in compliance with that policy.

In further aspects, the rules associated with a managed data objectand/or managed entity can be selectively definable for a plurality ofmanaged data objects and/or managed entities and/or third-party actors.The rules associated with the managed data objects, managed entitiesand/or third-party actors can vary as a function of the object and theparty. In other words, the rules are manageable and applicable based oncontext.

To this end, the compliance-related notifications can be automaticallyprocessed to determine whether they should be acted on in context. Thesharing of a managed data object may be out-of-compliance with agenerated rule, but may not require action thereon in a particularsituation. A type of managed data object, for example a protected healthrecord, may be subject to a non-sharing outside of the company policy.As such, an attempt to share that file may generate an out-of-compliancenotification as a matter of rule. However, if the person to whom thatmanaged data object is being shared is, in context, an appropriaterecipient of the data, the out-of-compliance indication can optionallynot be presented as a notification to a user. In this example, if acontractor, consultant, freelancer etc. is associated with a companyproject, department, employee, etc. and that association indicates thatsharing of the managed data object is appropriate in context, theout-of-compliance notification need not be made even though anindication that the processing event might have been out-of-compliancemay have been generated.

Yet further, a class of managed entities and/or actors can be associatedwith rules. In this regard, a rule can be generated that the CFO canshare any managed data object that incorporates SEC-regulated financialinformation unless the time period at the time of sharing is in amandated “Quiet Period.” Or, a rule can provide that the CFO can accessany files from any location unless there is a signal of a suspiciouslogin, such as multiple login attempts prior to a successful loginevent. Yet further, a CFO could be able to access and perform anyprocessing events on managed data objects, but the CFO’s direct reportcould be limited in the number of files that she could download in onelogin. Still further, any financial files shared outside theorganization (for example to a third party who is not a managed entity)can be associated with a rule that provides a notification of when thefile is shared, downloaded, copied, etc.

In some aspects, an out-of-compliance notification can be stored in adatabase record for reporting to a relevant department or governmentagency or to create an audit trail. Still further, suchout-of-compliance can trigger a notification to an IT (informationtechnology) administrator who can optionally act thereon. Yet further,such out-of-compliance with an applicable rule can trigger anotification of a relevant user, group, etc. This relevant user, group,etc. can be an identified user, group, etc. associated with a processingevent the managed data that triggered the out-of-compliancenotification. For example, if an identified user is an employee orotherwise within the management purview of the organization (e.g., afreelancer or consultant) or who is member of a group that owns ormanages that managed data object, a message can be sent to the user thather action was out-of-compliance with a rule associated with thatmanaged data object. The user or group of users can be sent a messagevia email, text, app, etc. along the lines of: “You recently shared[this file, calendar, etc.]. This action is not in compliance withcorporate [or group etc.] policy. Please ask the recipient to delete thefile and refrain from doing so again.” If the user who performed anout-of-compliance processing event on the managed data object is notunder the management purview of the administrator, for example, is athird-party actor, the message generated could be formulated to notifythat actor of a legal obligation existing as to that managed data objectthat might subject that actor to legal liability for unauthorizedactivities involving that managed data object. Still further, a managedentity could be instructed to notify the external user of theout-of-compliance activity and request that the managed data object bedeleted, returned, etc.

If an out-of-compliance notification is generated for a managed dataobject, one or more permissions associated with the managed data object,the managed entity and/or third-party actors can be modified in relationto that managed data object. Such permission modification can beautomatically generated by the system (for example by the compliancemodule), by an IT administrator, or both. As would be appreciated, anumber of permissions can exist for each managed data object, managedentity and/or third-party actors. In non-limiting examples, these caninclude: accessing, creating, viewing, merging, altering, sharing,sending, copying, printing, deleting, or modifying of the managed dataobjects. If a managed data object is shared improperly by one or moreusers, groups, etc. such that an out-of-compliance notification isgenerated, that user’s or group’s permissions can be modified to reduceor eliminate the occurrence of such out-of-compliance actions in thefuture. For example, a user’s permissions can be changed from “read,write, share, print” to only “read, write only” or “read only.”

Notably, out-of-compliance processing events performed on a managed dataobject by a user may be inadvertent. As a managed data object movesbetween and among various SaaS applications, the individual applicationscan assign their own set of permissions to a managed data object, asdiscussed previously. For example, the owner or manager of a manageddata object may have assigned a policy of “no print” to the managed dataobject, whereas a user of that managed data object in the cloudcomputing environment may have “SuperAdmin” permissions in the SaaSapplications in which the managed data object is operational. In thisregard, the SaaS applications would place no restrictions on the user’sprinting of the managed data object which would, of course, be inviolation of the “no print” rule placed on the object by the manageddata object owner or manager. The functionality of the presentdisclosure can enable the managed data object owner or manager at leastvisibility to actions that affect access to a managed data object, evenwhere the managed data object owner or manager may not have the abilityto preempt such actions because they are occurring at the level of theSaaS application. Such visibility can be critical in for managed dataobjects that comprise sensitive, regulated, or compliance-relatedmanaged data object: the requirement to protect such managed dataobjects from unauthorized access or disclosure exists even when it isdifficult, if not impossible, to physically stop such disclosures in thefirst place. To this end, by providing the owner or manager of thesemanaged data objects with timely notifications that of out-of-complianceprocessing events have occurred, any damage from unauthorized access ordisclosure can be mitigated, such as by notifying relevant users beforethe object is disclosed more broadly.

Further, timely out-of-compliance notifications can allow the owner ormanager of the managed data object to act on the user (e.g., managedentity, third party actor) whose activity on the object wasout-of-compliance. For example, if a minimal “data leak” resulting froman unauthorized sharing of a managed data object can be identifiedbefore substantial damage occurs, further data leaks can be reduced oreven prevented, such as by notifying the user or by revoking the user’ssharing permissions etc.

Notably, the definition of “timely” in regard to out-of-compliancenotifications depends on the context of the information and thesituations. For example, improper disclosure of protected healthinformation gives rise to liability immediately, even though thatdisclosure may not have resulted in a third-party’s gaining access tothat information. Thus, a “timely” notification of the disclosure ofprotected health information will ideally be immediate or substantiallyimmediate or at least as soon as possible. On the other hand, data leaksare often not recognized for some period of time by either the owner ora third party. Damage from that such leakage is therefore minimal sincethe data is not being accessed. If a third party does not access thatinformation, a timely notification may be commensurate with any periodof time prior to the access of a third party to that information, be itdays, weeks, or months etc.

In a further aspect, processing events performed on a managed dataobject at the level of a SaaS application irrespective of the type orvendor of the SaaS applications can be monitored, tracked, managed,audited etc. In other words, the present disclosure can provideheretofore unavailable systems and methods to allow global monitoringand tracking of actions taken on managed data objects that areoperational in a plurality of SaaS applications. This can allow anorganization to reduce or substantially eliminate liability resultingfrom inadvertent disclosure etc.

In a further aspect, the disclosure incorporates a data integrationplatform configured to align different versions of a managed data objectthat may arise during processing of managed data objects between andamong a plurality of SaaS applications operational in a cloud computingenvironment, wherein at least one of the applications is heterogeneous.As would be appreciated, the ability to accurately monitor, track,manage, audit etc. a managed data object in a cloud computingenvironment could be affected during processing thereof. To betterensure that a managed data object can be durably and accuratelymonitored, tracked, managed, audited etc., the present disclosuredescribes methodologies to integrate, align, normalize, etc. differentversions that may arise of a single managed data object duringprocessing thereof.

In some implementations, a first managed data object can undergo atleast some transformation or modification as a result of processing in afirst SaaS application such that this first managed data object maycomprise different content or characteristics after such processing. Forefficient and accurate treatment of the first managed data object in thecloud computing environment in subsequent processing events, a manageddata object version integration step can be conducted.

Such integration step wherein different versions of the first manageddata object can be integrated, aligned, normalized, merged, combined,resolved etc. can be conducted before or after the PID association stepis conducted for the subject managed data object. In a suitableimplementation, an extract, transform, and load (“ETL”) process can beperformed. Generally, the ETL processes can be operational in the cloudcomputing environment in real-time or substantially in real-time. TheETL functionality herein can be provided as standalone data integrationprocesses operational with other processes in the cloud computingenvironment, as built-in tools in database servers, or as components ofthird-party software offerings (e.g., “middleware”). Yet further, theETL processes can be fully integrated into the processes herein, suchthat a middleware product need not be operational therein. Stillfurther, and as would be appreciated, the data object integrationprovided by the ETL processes can enhance the flexibility and opennessof a user’s network computing environment by providing functionalitythat allows disparate SaaS applications to operate freely within andamong each other by putting an integration capability within the systemto allow a managed data object to be freely processed within them, whilestill allowing a managed data object to be monitored, tracked, managed,audited, etc. by the owner or manager thereof.

The data processed in the ETL functionality can comprise a managed dataobject that is derived from processing of the data object in one or moreheterogenous SaaS application processing events in that the data objectmay be processed to generate different versions of that single/firstmanaged data object, such as might occur when one or more heterogenousSaaS applications are operational in the cloud computing environment.

In some implementations, the ETL approaches can be applied in aparticular situation. For example, an ETL process that provides a fullset of information from an initial full synchronization can beperformed, followed by ETLs where only changes are identified (“deltasyncs”) or push notifications that inform on what operations have beenperformed on a managed data objects are synchronized in an ETL process.This can allow an updating of baseline information from a full set ofingested data with new information generated from processing of themanaged data object(s) in the cloud computing environment. As would beappreciated, a full synchronization can provide comprehensiveinformation of the operational characteristics associated with themanaged data object(s) as a set of baseline information, and after theinitial synchronization, the ETL process can be adjusted to receive pushnotifications to generate fewer API calls, and thus much fasterprocessing. In this regard, a “full sync” can take some time due to thedata ingestion operation, but this can provide a comprehensive overviewof the internal state of a user network. In contrast, “delta syncs” and“push notifications” can provide an ETL process that can be performed inreal time or substantially in real time. In some situations, theselatter synchronization types could generate incorrect or corrupted data.From time to time, it can be beneficial to conduct full synchronizationswhereby data is ingested to ensure that the information associated withmanaged data object(s) is not incorrect or corrupted. Therefore, the ETLprocess can comprise the full synchronization method on a definedrecurring basis, for example, every 12 hours, 1 week. 30 days, etc.,with synchronizations occurring therebetween being one or each of “deltasyncs” or “push notifications.”

In a first ETL approach, a full synchronization comprises a completedownloading of the processing events operational on a managed dataobject. Such full set of data acquired via ingestion can then becompared to a previous version, such as is present in a data graph, ofthat managed data object associated with a PID. From this comparison,processing events that occurred in the cloud computing environment onthat managed data object can be determined, such as, creation, deletion,modification, sharing, and operations that an actor (e.g., a managed orunmanaged entity) may have performed on such object in the cloudcomputing environment, as well as any relevant information that may bederivable from the managed data object itself.

A second ETL approach comprises an evaluation of changes to a manageddata object from processing events occurring between a first processingevent or time and a second processing event or time. The managed dataobject condition or content or status can be a baseline assessment ofthe managed data object, for example, a managed data object associatedwith a PID. The second check can be an assessment of the processingevents operational on a managed data object and/or changes made to thedata object during or as a result of one or more processing eventsoccurring after the first check, where the changes can be seen fromdifferences with the managed data object having the PID associatedtherewith. Such processing events can be related to data objectcreation, deletion, modification, sharing, etc. and operations that anactor (e.g., managed or unmanaged entity) may have performed on suchobject in the cloud computing environment.

A third ETL approach comprises identifying the processing eventsoperational on a managed data object directly from the SaaS applicationwhich was operational thereon. Events that occurred in the cloudcomputing environment on that managed data object can be derived, suchas, creation, deletion, modification, and operations that an actor(e.g., managed or unmanaged entity) may have performed on such object,such as by comparison between the processed managed data object and thepersistent managed object-that is, the data object having a PIDassociated therewith. Push notifications of processing operations can begenerated by a SaaS application operational on the managed data object,and such push notifications from an API can be useful in the ETL processsuch as by providing an inventory of actions performed on or in relationto the managed data object during processing thereof.

Each event that is identifiable as operational on a managed data objectcan then be enriched to a full state so as to provide a maximized changeset that allows pertinent information associated with the managed dataobject to be derived. In this regard, events consisting of useridentifications, for example, can be enriched such that information canbe derived therefrom via evaluation of information present in metadata.Put another way, the information generated from the ETL step can beprocessed by performing additional lookups to build up the full contextfor all entities involved in a reported processing event occurring inthe cloud computing environment.

By way of example, information, such as a push notification from an API,may provide information only for an actor’s “UserId.” with the remainderof that actor’s associated information (e.g., permissions, status,ownership, etc.) being located elsewhere in the applications environmentThus, a processing event for each managed data object and any pertinentassociated information is “enriched to its full state” to enhance thecontext of a processing event to allow determination of the condition orcontent or status of a managed data object after processing in the cloudcomputing environment in a plurality of SaaS applications. For example,Google does not push notifications relevant to a user’s title changes.In order to obtain context-relevant information about a processing eventassociated with a managed data object that includes rich informationabout title changes for a user associated with a managed data object, a“UserId” provided from an API is built out, or “enriched” withinformation available that is relevant to that provided “UserId” that ispresent in metadata incorporating or associated with that metadata. Insome implementations, such enriched data enables detection of processingevents via a direct notification, such as by a push notification. Forexample, when a user joins a group, a push notification can be generatedas for that action; in addition, rich context can be generated aboutthat user that may not be explicitly identified by an API, e.g.information about changes in user’s titles. Such fully enriched statefor each managed data object can then be compared to a persistedstate-that is, the same data object having a PID-to derive informationabout processing events that were operational on that managed dataobject in the cloud computing environment.

An output of any of the described ETL approaches could optionallygenerate a subsequent ETL process. For example, information generatedfrom an ETL process associated with the updating of a group in which amanaged data object is associated could generate a ETL processing eventthat provides information about group membership that would potentiallyprovide information about operations performed on a managed data objector a plurality of managed data objects by members of the group. Asanother example, a change to file sharing permissions associated with amanaged data object and/or a managed entity could generate an ETLprocessing event associated with a plurality of managed data objectsassociated with these file permissions.

An output of ETL processing events is a data graph. The generated datagraph informs relationships between the managed data objects and managedentities. The generated data graph also provides information associatedwith the ETL processes, as well as PID-association processes.Information derivable from the generated data graph can thus be usefulto update and/or modify one or more processes operational in the cloudcomputing environment.

In some implementations, processing of a first managed data object inthe cloud computing environment may not result in different versions ofthe same data object, even when the SaaS applications are heterogeneous.In this regard, processing can be performed that determines whethermultiple versions of the same managed data object have been generatedfrom processing thereof in the cloud computing environment. If suchdetermination indicates that multiple versions of the same managed dataobject are not generated after processing of that managed data object inthe cloud computing environment, no data integration step need beconducted.

In further implementations, the associated managed data object versionintegration processes can be associated with integrated managed dataobject mapping functionality, thereby allowing tracking, management,auditing, and viewing thereof. The integrated managed data object andassociated functionality can also be stored as separate operationalprocesses to allow a managed data object integration routine to bedeployed in a subsequent data integration operation, thereby enablingthe generation of repeatable integration operations within the same ordifferent cloud computing environments.

In a significant implementation, the systems and methods can providecentralization of a plurality of SaaS applications operational in acloud computing environment. “Centralization” refers to the state ofhaving a comprehensive consolidated view of managed data objects and theactions taken thereon that may be operational across one or multipleSaaS applications in one place, such as via a dashboard. The entireframework can be associated with centralization of a plurality ofmanaged data objects connected across applications. Significantly, thecentralization provided by the present disclosure can allow not onlyvisibility to users outside of the organization, but can also provideinformation about the actions these external users are taking on themanaged data objects.

In regards to such centralization, an information set can be generatedthat can be provided in the form of a data graph that is viewable on amonitor, printable from a device, or otherwise recordable in a database.Processing events taken on the managed data objects can also beincorporated in the information set and, optionally, viewed, printed, orrecorded in a database record.

The methods and systems disclosed herein can be used in a networkcomputing environment to allow a unified dashboard to be generated tomonitor, track, manage, audit, etc. processing events performed onmanaged data objects within and among a plurality of SaaS applicationsby managed entities and/or third-party actors. In this regard, thesystems and methods of the present disclosure can allow the owner ormanager of managed data objects to centralize control of, orchestratecomplex actions upon, and/or delegate administrator permissions withrespect to such managed data objects across a plurality of SaaSapplications. Still further, the present disclosure allowscontextualized event logs to be generated across a plurality of SaaSapplications, where such event logs are viewable in the unified view.

In non-limiting examples, the following may be manageable (e.g.,visualizable, actionable, etc.) from a centralized location, such as adashboard, even though the managed data objects relevant to suchprocessing event may have been processed by a plurality of SaaSapplications:

-   · Which third-party applications have access to the organization’s    managed data objects?-   · What kind of access do they have?-   · What kind of administrative permissions do employees have across    SaaS applications?-   · What is each user and/or administrator doing in each SaaS    application?-   · What kind of member access, sharing options, and settings do the    organization’s groups have (e.g., who can view the group, members,    and member email addresses; who can add/remove people; who can post    topics, etc.)?-   · How many managed data objects (e.g., files, calendars, etc.) are    publicly shared?-   · Who has super admin access, either for a single SaaS application    or multiple applications?-   · What are all the pages that exist on the domain (e.g., a company    Intranet, client project sites)?-   · What automations/workflows are set up in a single SaaS application    or across multiple applications?-   · How can IT view contextualized event logs across SaaS    applications?-   · Login information (e.g., location, date, time)-   · Email signature compliance

In an implementation of this aspect of the present disclosure,onboarding, offboarding, information security, system maintenance,operational efficiency for users, groups, etc. can be facilitated withthe present disclosure.

“Onboarding” means the introduction of a user, group, etc. to an ITenvironment, such as when a person is hired as a new employee, afreelancer or consultant is engaged to assist in a project, or anemployee is moved to a new position or department. In other words,onboarding is the process of equipping new users, groups, etc. with theproper tools needed to complete tasks associated with such users,groups, etc. This can include, for example, provisioning new accounts,providing users with access to managed data objects such as shared filesand folders, adding them to the right groups, applying email signaturesthat comply with organizational standards, etc. There are variousanalogs of onboarding, where key aspects of this activity includeintroducing a new user to an IT environment, granting permissions tothat user as to access a collection of managed data objects, anddefining rules related to the processing events that a managed entity(e.g., an employee) can perform on such managed data objects. Inaccordance with implementations, onboarding of a user, group, etc. to anIT environment comprising a plurality of SaaS applications can besubstantially automated with the systems and methods described herein.Such automation is enabled, at least in part, due to the centralizedmanagement processes provided herein.

“Offboarding” means the removal of a user, group, etc. from an ITenvironment or part of an IT environment, such as when a person isremoved as an employee, a freelancer or consultant is disengaged fromassisting in a project, or an employee is moved to a new position ordepartment where permissions related to previously accessible manageddata objects need to be modified. Offboarding is the counterpart ofonboarding. An offboarding process can comprise, for example, steps ofdeprovisioning a managed entity’s (e.g., employee) accounts, changingpasswords, transferring managed data objects (e.g., files, devices,etc.) ownership, delegating mailboxes, etc. There are various analogs of“offboarding,” where key aspects of this activity include removing anexisting user from an IT environment or part of an IT environment,removing permissions assigned to that user as to access to managed dataobjects, and defining rules related to the processing events that can betaken on such managed data objects. In accordance with implementations,offboarding of a user, group, etc. from an IT environment comprising aplurality of SaaS applications can be substantially automated with thesystems and methods of the present disclosure.

“Information security” means the task of preventing unauthorized access,use, disclosure, disruption, modification, copying, or deletion to or ofinformation that is relevant to the operations of an organization. Thesystems and methods of the present disclosure facilitate the use of aplurality of SaaS applications in a cloud computing environment byallowing managed data objects to move appropriately between and among aplurality of SaaS applications and within and through managed entitiesand/or third-party actors so as to enhance user productivity and toallow effective collaboration, while at the same time allowing the owneror manager of such managed data objects to implement and monitor theimplementation of rules to make sure that the security of such manageddata objects is not compromised. Specifically, the systems and methodsof the present disclosure can affect data loss protection (“OLP”) in acloud computing environment by implementation of either or both of acontent discovery policy or a sharing policy.

A content discovery policy allows managed data objects to be identifiedaccording to a selected category, type etc. so as to allow movementthereof to be monitored through a computing network. Content discoverypolicies may seek to identify manageable information that should beprevented from unauthorized disclosure or use (e.g., such as SocialSecurity numbers. credit card numbers, bank account numbers andpersonally identifiable information) that should may travel through andamong a plurality of SaaS applications and that, in some circumstances,may be undesirable to store in such applications. By facilitating OLPfor such managed data objects, damage to the organization that willresult from data loss (e.g., reputation, revenue loss, fines, customertrust, reputational effects, etc.) can be reduced or even substantiallyprevented.

In some aspects, a managed data object can be reviewed by the systemautomatically at the network computing module level, for example, suchthat a content discovery policy can be implemented, to determine whetherthe managed data object includes sensitive or compliance-related data.For example, a file, calendar, device etc. can be automaticallyreviewable to determine whether any personally identifiable informationis associated therewith. In accordance with the managed data objectaspects, the assignment of a PID to a managed data object can enhancethe effectiveness of a content discovery policy at least because theidentity of the managed data object can be automatically processed evenif the data object identity has been modified/de-correlated from amanaged entity at the SaaS application level.

Sharing options associated with SaaS applications are a “feature” forusers in that users, groups, etc. can share documents, spreadsheets,presentations, calendars, etc. with specific persons, anyone in anorganization, or even publicly, allowing others to read, comment, and/oredit the shared item. For IT administrators, these sharing options areoften a “bug.” For example, some SaaS applications, such as Slack, setthe sharing settings automatically to “public,” thus users of Slack mayinadvertently allow sensitive or compliance-related managed data objects(e.g., files, calendars, etc.) processed in that application to beviewed without restriction if he does not first set the Slack sharingsetting to “private.” As would be appreciated, public sharing of manageddata objects can cause significant damage to an organization becauseanyone within the organization or even on the whole internet can locateand access them. Moreover, the proliferation of SaaS applications wherethe sharing settings are defined by an entity who has no concerns abouthow a user’s data is shared or maintained makes it more likely thatsensitive or compliance-related managed data objects may inadvertentlybe publicly shared as a result of SaaS applications usage, especiallygiven the propensity of software developers to prefer open access toinformation on the internet. Indeed, some software developers may noteven recognize the need to protect managed data objects that use theirSaaS applications because protection of data is typically anorganizational function, not that of an individual. Because SaaSapplications are typically acquired at the user level, it follows thatthese applications can comprise a significant “security hole” incorporate data protection operations.

The present disclosure allows sharing settings for SaaS applications inwhich managed data objects are processed to be reviewed by an ITadministrator at the network operational level so as to allowidentification any sharing settings on SaaS applications that couldresult in data loss. Such viewing is possible even though the ITadministrator may not possess the ability to change such settings. Inthis regard, the methods herein allow managed data objects associatedwith SaaS applications that incorporate public sharing settings to bevisible from a dashboard environment, for example. Still further, formanaged data objects that are identifiable as incorporating sensitive,regulated, or compliance-related data therein (e.g., when a contentdiscovery module is present), automatic notification of the managedentity correlated with that managed data object or a relevantthird-party actor of such out-of-compliance sharing settings can beprovided. Yet further, a report and/or an audit can be conductedautomatically according to the present disclosure. In someimplementations, out-of-compliance sharing may be acted on by either orboth of a computer or a user (e.g., an IT administrator).

Yet further, the systems and methods of the present disclosure can allowadministrative rule applications to be tracked, managed, audited etc. bygiving visibility to the processing events performed on a selection ofmanaged data objects. In this regard, actions that are taken on aselected and managed data object can allow the permissions associatedwith a SaaS application to be inferred, even though they might not beactually viewable at the network administrator level. As can beappreciated, it can be beneficial to reduce the number of permissionsassociated with a user, group, etc. In this regard, some SaaSapplications, especially those that may be less mature in developmentform, may offer only binary administrator options: super admin or enduser, with nothing in between. Accordingly, users who only need a fewpermissions may nonetheless be designated as “super admins.” “Superadmins” are users who have full access to all system administrativecontrols and features in SaaS applications. They have the highest levelof permissions, and can therefore manage all aspects of a SaaSapplications to which they have such permissions, including thehighest-level security and admin settings. They will thus have fullcreate, read, update, and delete (“CRUD”) permissions to a managed dataobject at the SaaS application level, even when their permissions may beless at the corporate level. If CRUD permission information can bereceived, a notification of Super Admin permissions can be provided, andcorrective action can be taken thereupon. For example, access roles thatoutline which administrative functions that users (e.g., managedentities and/or third-party actors) can and cannot perform can bedefined, and the user can be instructed to adjust his permissions tothese values at the SaaS application level. For example, a user can beassigned specific roles and security levels depending on his position,department, etc. Such notifications and actions taken thereupon can beautomatic, by an administrator, or both.

Still further, the present disclosure allows the identification ofexternal users that have access to managed data objects that maycomprise sensitive or compliance-related data. “External users” caninclude anyone who is not a recognized employee of an organization butwho is associated with completion of one or more tasks on behalf of theorganization. Such external users can include freelancers, interns,consultants, contractors, and/or service providers. In a typicalsituation where a task or activity is conducted only within anorganization, a group of users will comprise only employees. However, ina modern corporate environment, external users are often brought on tocomplete a task or activity. At least due to the fact that theseexternal users are not part of the corporate infrastructure-for example,they do not have human resources files or identifiers that can betracked-it can be exceedingly difficult to track them for onboarding andoffboarding. As a result, such external users can retain access tomanaged data objects beyond the date when their work is completed. Thisgives rise to the risk that sensitive, regulated, or compliance-relatedmanaged data objects can be improperly accessed by the external users,or even shared by them intentionally or inadvertently. The systems andmethods herein allow notification of external users, and suchnotifications can trigger the recovery of managed data objects to whichsuch users may have had access, such as by removing their access tofiles, folders, calendars, etc. Such action can be via a centralizedlocation and, in some aspects, can be conducted substantiallyautomatically.

Moreover, users, both internal and external, can often add users veryeasily. In some cases, end users can create their own groups, addinternal and external addresses to groups, and allow anyone inside andoutside of an organization to join a group. In some SaaS applications,if the ability to add users is removed as a permission, any externaladdresses already added will remain in those groups. If an ITadministrator does not know about these users, there is no way to managetheir access and, as such, managed data objects can be compromised. Inaccordance with such internal and external user access management, thepresent disclosure provides a systems and methods to track, manage,audit etc. whether internal and external users have access to manageddata objects, such as those comprising sensitive or compliance-relatedinformation and, optionally, who these users are, what their roles andresponsibilities are, who their contact/supervisors are, among otherthings. Still further, notice can be provided when internal and externalusers are added, where such notice results from receivable processingevent information. Still further, an internal or external user can beoffboarded if it is determined that she is no longer working in or withthe organization. Such offboarding can be substantially automatic, orcan be conducted by an administrator/manager or both.

When the generated information set is presented in the form of a datagraph, an IT manager can visualize processing events performed on one ormore managed data objects at the SaaS applications level. This can allowprocessing events performed on the managed data object(s) to bemonitored, tracked, managed, audited etc. from a centralized location.For example, an IT administrator can monitor whether and to what extenta managed data object has been accessed, copied, printed, modified etc.across a plurality of SaaS applications in real time or substantially inreal time. Such information is viewable, for example, in a grid form forprocessing events performed on a single managed data object in Google,Slack, Dropbox, Box, etc. In this regard, rules associated with themanaged data object can be consistently applied across a plurality ofSaaS applications in accordance with the systems and methods of thepresent disclosure.

In a further example, the present disclosure can allow automaticmanagement of a plurality of granular actions of a user or a group ofusers from multiple areas across a plurality of SaaS applications,including memberships, settings, third-party applications, and more.Such actions are indicated by processing event information that isreceivable.

In a further aspect, the methods and system herein can be automaticallyenabled once a first action occurs repeatedly, that is, as a patternemerges. In this regard, when specific actions associated with a manageddata object are indicated to be out-of-compliance with one or morerules, the system can automatically address, such as by mitigation, theeffect of the-out of-compliance processing event, thereby creating asubstantially self-healing environment.

Yet further, rules can be associated with a managed data object orclass/type of managed data objects as a function of authorized andunauthorized activities within a time period, location, and/or number ofactions. For example, a rule can be generated that allows a managed dataobject that is of the class “marketing brochures” to be downloaded up tox number of times per hour by a third-party user who is located within acertain geographical location or who is associated with a particular IPaddress. If a user is associated with a location or an IP address thatis that of a competitor, the marketing brochures can be limited to one(or none) per a time period. Still further, a rule can be generated toprovide a notification when more than x number of files are downloadedin y time period from IP addresses that are not associated with acompany’s internal network.

In further aspects, the present disclosure allows an administrator toidentify from a centralized vantage point, such as a dashboard, whenmanaged data objects incorporate a sharing setting of interest, forexample, public sharing, group sharing, external sharing even ifnon-public, or the like, and to determine whether and to what extentsuch managed data objects have been shared both within and outside ofthe organization. In conjunction with this implementation, an ITadministrator can also determine whether a one or a plurality of SaaSapplications retains access to the managed data object, irrespective ofwhether the administrator has administrative control over those one ormore SaaS applications. In a further implementation, the sharing ofmanaged data objects outside of an organization, that is, via one ormore SaaS applications can be monitored, managed, audited etc. Suchnotice of sharing can be provided via an information set incorporatingprocessing information generated from the SaaS applications, where suchinformation set can be configured into one or more data graphs. Furtheraspects can allow the identity of the person or entity with which themanaged data object is being shared to be identified, for example, acompetitor etc. For example, if a user shares a managed data objectcomprising sensitive, regulated, or compliance-related information,notification of such sharing can be provided, and action can be takenthereupon as described elsewhere herein. For example, when the manageddata object is a file or calendar and the sharing setting of interest is“public,” an administrator can determine whether such file or calendarwas shared publicly, as well as to identify the users who still retainaccess to such file or calendar. Yet further, the present disclosure canidentify SaaS applications that possess at least some access to thefiles or calendars.

As would be appreciated, providing an administrator with the ability togain visibility as to whether and to what extent a managed data objectis accessible outside of a specific user, group, organization, etc. canenhance information security in a computing network. If an authorizedparty possesses access to an organization’s sensitive, regulated, orcompliance related managed data objects-be it in the form of files,calendars, devices, or otherwise-the organization may lose competitiveadvantage and/or be subjected to regulatory action.

The administrator can also gain insights into whether a particularmanaged entity is in compliance with rules associated with her positionor department. For example, if an employee is found to be accessingfiles that are not associated with her job description, it might beinferable that the person needs management intervention, such as bycounseling or even termination.

To determine whether a rule associated with a managed data object and/ormanaged entity has been out-of-compliance with an associated rule, fromtime to time, an audit can be conducted. Auditing is an effectivestrategy for passively monitoring compliance with established manageddata object rules. Because in most cases audits will not be activelyinterfering with end users’ use of a SaaS applications, it is alow-touch approach to enforcing rules regarding managed data objects.Compared to a more active strategy (e.g., a data loss prevention policywhich alters document permissions or sends alerts), passive audits canprovide the owner or manager of a managed data object with theflexibility to decide which processing events require action. Even if anorganization does not have a strict or clearly defined rule for amanaged data object type, a periodic audit can offer valuable insightsinto how managed data objects are being handled both internally andexternally, as well as to the manner that employees and other withaccess to the managed data objects are behaving in the cloud computingenvironment. The scope of external managed data object exposure revealedby an audit can generate insights as to whether more aggressivemeasures, such as managed data object recapture or user permissionrevocation, need to be taken to prevent a data breach from occurring orto mitigate damage from one that has already occurred.

Managed data objects that are suitable to share at the management levelmay be problematic, or even illegal, to share more broadly in theorganization. Thus, managed data object and user context can be relevantin a cloud computing environment. If someone is given access to a typeof managed data object and then moves to another position in theorganization, access to the managed data object type that was relevantto her first position may not be relevant to her current position, andaccess to that previously relevant managed data object may even beprohibited. Thus, it could be beneficial to revoke access to manageddata objects that are no longer applicable to her current position. Insome, but not all, situations, it may also be appropriate to revoke ormodify the permissions to other users for the managed data objects towhich the first person granted access. If the first person is no longercollaborating with others in relation to one or more managed dataobjects, the present disclosure allows permissions granted to the firstperson to be automatically revoked or modified upon the first person’sstatus change modification. The permissions of others to managed dataobjects that was given by her can also optionally automatically berevoked or modified upon the first person’s status change notification.

As a non-limiting example of this implementation, when a user’s internaljob description is updated in a human resources or other database, suchstatus change can be provided to the administrator automatically vianotification. For example, if a user’s department number is changed,that change can be provided to the IT department, and access to manageddata objects and permissions associated therewith can be automaticallygenerated. The system can be configurable to substantially automaticallyidentify all managed data objects—where such managed data objects havebeen processed in accordance with aspects of the present disclosure—thatare associated with the user’s prior position, and access to thosemanaged data objects can be revoked or modified according to a generatedpolicy. Managed data objects that the user shared with or to which shegranted access to third parties prior to the status change can beidentified and actions can be taken thereon as appropriate. Such sharingor access can be identified in relation to the status or location of thethird party, for example, if he is an employee of the organization or ifhe is someone who is not a recognized employee of the organization thethird party’s permissions with respect to the identified managed dataobjects can be revoked or modified according to a generated policy.

In some aspects, the assess or permissions to the managed data objectscan optionally be revoked depending on the user and context. In somecases, all permissions granted by the first person may be revoked. Inother cases, only the permissions of persons outside of the organizationmay be revoked. Yet further, permissions held by only some of thepersons to the shared managed data object may be revoked, whether or notthey are inside or external to the organization. In this latter case,the person changing positions may maintain certain external staffing,such as freelancers or consultants, who report to her directly on aregular basis. Such persons would not need to maintain access to themanaged data objects pertinent to the first person’s prior position, andit would be beneficial, if not imperative, for their access to berevoked to the managed data objects to which her access was revoked. Incontrast, any persons who remained as freelancers or consultants to thedepartment or, more specifically, project, would need to retain accessto the managed data object after the first person changed position.

In separate aspects, the systems and methods herein are configurable toallow determination of the relationships between users, groups, etc. andto define rules pertinent to managed data object access, where suchpolicies are associated with the type of relationship between users,groups, etc. For example, a manager can be associated with the employeesthat she supervises, her manager(s), and any users, groups, etc. thatare defined as support for her department. Other users or groups can beassociated with their functions: for example, human resources personscan be associated with department managers etc.

A newer issue with the unfettered access that many SaaS applicationsprovide to third party users is the ability that such access may provideto those with nefarious intentions. To this end, if an external user isgiven access to sensitive data by way of being granted permissions thatare native to a SaaS application associated with a managed data object,the external user can abuse her permissions to misuse the organization’sdata. It follows that a highly beneficial implementation can be theability for administrators to visualize and manage the movement ofmanaged data objects between and among a plurality of SaaS applicationswhere the users having access to such managed data objects are bothwithin and external to the organization. This can better enable anorganization to ensure that sensitive, regulated, and compliance-relateddata is not inappropriately used outside of the organization. This alsoallows an organization to monitor, track, manage, audit, etc. processingof managed data objects among a plurality of SaaS applications so thatdamage from improper access and/or use of sensitive, regulated, orcompliance-related data can be mitigated or even eliminated by theability to respond quickly to data misuses.

The systems and methods herein can facilitate enforcement of granularrules based on content profiles to prevent potential data leakagescenarios and allow continuous compliance. In another implementation,SaaS applications operating in a cloud computing environment can beretroactively evaluated, such as in an audit situation, against thecontent profiles for discovering sensitive data that may have alreadybeen processed in ways that are out-of-compliance with current rules. Insome implementations, the enforcement is global and can apply tosubstantially all SaaS applications interfacing with the organization’snetwork. In other implementations, the enforcement can be applied toindividual SaaS applications or to a category of SaaS applications.

In particular, the systems and methods herein can allow the monitoring,tracking, management, and auditing etc. of managed data objects in agranular context, such as in relation to user, group, location, IPaddress, device/hardware, service, category, activity, and content.among others. Unlike solutions for which access to SaaS applications isan all-or-nothing proposition, the systems and methods herein can alloworganizations fine tune via selection the actions/reactions that areconducted in response to processing events that may be performed on amanaged data object or by a managed entity and/or a third-party actor atthe SaaS applications level. In other words, the methods herein alloworganizations that have a need and/or obligation to track, manage, ormaintain an audit trail associated with such managed data objects,managed entities, or third-party actors to do so.

Compliance with a wide variety of generated rules can be evaluated andenforced with the systems and methods herein, As non-limiting examples:

-   When users download content deemed “confidential” from a cloud    storage service to an unmanaged system or device.-   When a user attempts to sign into a virtual private network (VPN).-   Any user having access to compliance-related information (e.g.,    human resources, investor relations) shares files, calendars, etc.    with someone outside of the organization or downloads such    information to a mobile device.-   A user downloads or shares contacts from any CRM service-   Download of any .exe file from a cloud storage service.

As would be appreciated, security of managed data objects, such asfiles, calendars, devices, etc. can be affected by a system thatevaluates processing events or user actions in accordance to generatedrules, and either allows or blocks such processing events. Anyprocessing events performed in a cloud computing environment can then beregulated prior to allowing an action to occur. This “blacklist” and“whitelist” process can slow down the system, frustrate users, andprevent them from doing their jobs. Moreover, the sprawling nature thatexists with the proliferation of SaaS applications now, which will beeven more prevalent in the future, can be expected to greatly increasethe number of actions that need to be checked. Thus, a managed dataobject security system with or without user access capabilities thatoperates on a blacklist/whitelist methodology are likely to become toocumbersome to use in an IT environment where SaaS applications is therule or majority.

Notably, the present disclosure does not “whitelist” or “blacklist” SaaSapplications, that is, the systems and methods herein do not firstdetermine whether to allow or block processing event types performed bya particular application prior to allowing a processing event to takeplace in the cloud computing environment. Instead, the presentdisclosure allows internal and external users, groups etc. to acquireand deploy for use a plurality of SaaS applications, one or more ofwhich can be heterogeneous with respect to another, to generate thedesired functionality for a given operation. Notwithstanding this broadflexibility, the present disclosure can provide administrators, such asan IT department, to monitor, manage, audit, etc. managed data objectsand users in the cloud computing environment, even though there may belittle or even substantially no administrative control over one or moreof the applications themselves. The present disclosure can thereforeaddress the competing and previously often incompatible goals of broaduser access to functionality on an as-needed basis and the need for ITadministrators to be able to track the movement of and user access tomanaged data objects.

The present disclosure operates in an alternate managed data objectsecurity model in that by providing notification of an out-of-complianceprocessing event performed on a managed data object, a notification canbe provided regarding such event, so that event can be prevented in thefuture (e.g., notifying a user, removing permissions etc.), damageremedied (e.g., seeking return/deletion of the managed data object), orgenerating a report thereof (e.g., reporting to an appropriatedepartment or agency as required by policy). The systems and methodsherein can facilitate the tracking of managed data objects and theactions of users through and among a plurality of SaaS applications byproviding an auditable trail of the managed data objects and useractions within and among the cloud computing environment. For example,the downloading of proprietary data from an organization’s database to aSaaS applications storage system (e.g., Dropbox, Google Drive etc.) canbe tracked and matched to a managed entity and/or a third-party user. AnIT administrator can generate a forensic audit trail showing movement ofmanaged data objects by every cloud service action for that user leadingup to and immediately following the incident. This would enable IT notonly to uncover suspicious behavior, but also to prove a breach occurredand clearly demonstrate malicious or criminal activity.

Upon receiving of information about a processing event performed on amanaged data object that is out-of-compliance with one or more rules,one or a plurality of actions can be affected by the system, includingin non-limiting examples, alert, quarantine, coach, initiate a workflowto remediate, record, seek justification, or report on theout-of-compliance event or activity. The type of action effected can bebased on at least one of the type of the rule implicated by the actionon the managed data object, the activity being performed on the manageddata object by each user, and/or the type/content of the managed dataobject. In other implementations, other actions can be triggered, suchas changing the ownership of the managed data object and/or permissionsassociated therewith.

Referring Now to the Figures

FIG. 1 is a drawing of a computing environment 100 according to variousembodiments of the present disclosure. The computing environmentincludes a plurality of provider computing systems 101 a-n. A providercomputing system 101 may comprise, for example, a server computer or anyother system providing computing capability. Alternatively, the providercomputing system 101 may employ a plurality of computing devicesarranged, for example, in one or more server banks or computer banks orother arrangements. Such computing devices may be located in a singleinstallation or may be distributed among many different geographicallocations. For example, the provider computing system 101 may include aplurality of computing devices that together may comprise a hostedcomputing resource, a grid computing resource and/or any otherdistributed computing arrangement. In some cases, the provider computingsystem 101 may correspond to an elastic computing resource where theallotted capacity of processing, network, storage, or othercomputing-related resources may vary over time. The provider computingsystem may implement one or more virtual machines that use the resourcesof the computing system.

Each provider computing system 101 provides one or more softwareservices 103 in the form of a SaaS application within a cloud computingenvironment. As discussed hereinabove, one or more of the SaaSapplications operational in cloud computing environment can beheterogeneous, as such term is defined in this disclosure. For example,a particular provider computing system 101 a may execute a softwareservice 103 such as a messaging or communication service, documentcreation/management service, CRM service, group collaboration service,hardware device control, etc.

Within a provider computing system, various data is stored in a database106 or other memory that is accessible to the provider computing system101. The database 106 may represent one or more databases 106. Thedatabase 106 may store managed data objects 109 and user accounts 112. Auser account 112 includes information to allow a user to register withthe software service 103, access the software service 103, and create,edit, or otherwise manipulate managed data objects 109 handled by thesoftware service 103. User accounts 112 for the software service 103 areused to facilitate a user login. A particular provider computing system101 a creates a different application instance for each user accordingto a corresponding user account 112. Software services 103 are typicallyprovided on a subscription basis such that subscriptions are trackedaccording to user accounts 112.

The computing environment 100 includes a network 115 such as theInternet, intranets, extranets, wide area networks (WANs), local areanetworks (LANs), wired networks, wireless networks, or other suitablenetworks, etc., or any combination of two or more such networks, Theprovider computing systems 101 a-n provide cloud computing services overthe network 115.

The computing environment 100 further includes a management platform 118connected to the network 115. This platform 118 embodies the varioussystems and implements the various methods described in the presentdisclosure. The platform 118 is a computing system. The platform 118 maybe deployed as a private cloud, a community cloud, a public cloud, or ahybrid cloud. The platform may comprise, for example, a server computeror any other system providing computing capability. Alternatively, theplatform 118 may employ a plurality of computing devices that may bearranged, for example, in one or more server banks or computer banks orother arrangements. Such computing devices may be located in a singleinstallation or distributed among many different geographical locations.For example, the platform 118 may include a plurality of computingdevices that together may comprise a hosted computing resource, a gridcomputing resource and/or any other distributed computing arrangement.In some cases, the platform 118 may correspond to an elastic computingresource where the allotted capacity of processing, network, storage, orother computing-related resources may vary over time. The platform mayimplement one or more virtual machines that use the resources of thecomputing system.

The platform 118 forms part of the cloud computing environment discussedabove. The platform 118 executes a management application 121 thatprovides the functionality described above with respect to managed dataobjects 109 and entities 127. The management application 121 may beimplemented as a multi-tenant SaaS application that interfaces withvarious heterogeneous software services 103 of different providercomputing systems 101 a-n.

Within the platform 118, various data is stored in a database 124 orother memory that is accessible to the platform 118. The database 124may represent one or more databases 124. The database 124 may storemanaged entities 127, managed entity identifiers (IDs) 130, persistentIDs (PIDs), compliance records 136, rules 139, and permissions 142. Amanaged entity 127 reflects information about an actor such as, forexample, a user, that interacts with a managed data object 109. This mayinclude a user name, account information, or other data associated witha user or actor. The managed entity ID is an identifier to uniquelyidentify a managed entity 127. A PID 133 is assigned to a correspondingmanaged data object 109 to allow management and tracking of the manageddata object 109. A database record 139 such as a compliance record (alsoreferred to a non-compliance record) is a data log reflecting actionstaken on a managed data object 109 and an indication of whether theaction is in compliance with one or more of a permission 142 or rule139. Rules 139 may include policies or protocols that govern how manageddata objects 109 should be processed or otherwise manipulated incomputing environment 100. The generation of a rule 139 may beassociated with one or more permissions 142. In this regard thepermissions 142 may be associated with one or more rules 139 definablefor either or both of the managed data objects 109 or identified managedentity 127; and one or more processing events performable on the manageddata objects 109 by the identified managed entity 127.

The computing environment 100 further includes a client environment 145connected to the network 115. The client environment can include thevarious client devices associated with a particular organization. Thismay be the collection of an organization’s laptops, mobile devices,desktops, servers, tablets, IoT devices, vehicles, or other hardwaredevices having computing capability. Users of these client devices caninteract with the software services 103 of the cloud computingenvironment 100. The management application 121 tracks the actions andactivities initiated from the client environment as users processmanaged data objects 109. The client environment 145 refers to anyclient device used to process managed data objects 109. The clientenvironment 145 as described herein can also refer to client devicesused by unauthorized users who falsify their identities to breach anorganization’s security.

Within the computing environment 100, a processing event 148 istriggered from the client environment 145. A processing event 148 may betriggered by a managed entity using a client device within the clientenvironment 145 or by a third-party actor operating outside of theclient environment, where such third party action is associated with oneor more managed data objects 109. A processing event 145 may also betriggered automatically by a script or program that automates processingevents 145 to be generated.

A processing event 145 includes an instruction or command that is sentto a particular software service 103 for the purpose of accessing (e.g.,downloading), creating, viewing, merging, altering, sharing, sending,copying, printing, deleting, or modifying of the managed data objects amanaged data object 109.

Within the computing environment 100, processing event information 151is received by the management platform 118. For example, the platform ismade aware of any processing events 148 by monitoring the actions takenby various software services 103. The management application 121 may useSaaS vendor-available APIs to receive information about data changes andevents associated with processing of managed data objects 109.

Within the computing environment 100, the platform 118 generatesdata/alert 154. The data/alert 154 may be real-time data that indicatesdifferent analytics on processing events, reports that reflectprocessing events, records of non-compliance where a processing eventviolates a rule 139 or a permission 142. The data/alert 145 may also begenerated in conjunction with a data graph that graphically depictsinformation pertaining to processing events 148 triggered by a clientenvironment 145. The data alert 154 provides centralization of aplurality of SaaS applications, even though one or more of the SaaSapplications are heterogeneous.

FIGS. 2A-D represent examples of portions of the functionality of themanagement application 121 (FIG. 1 ) executed in a computing environment100 of FIG. 1 , according to various embodiments of the presentdisclosure. It is understood that the flowcharts of FIGS. 2A-D providesexamples of the many different types of functional arrangements that maybe employed to implement the operation of the portion of the managementapplication 121 as described herein. As an alternative, the flowchartsof FIGS. 2A-D may be viewed as depicting an example of elements of amethod implemented in the computing environment 100 according to one ormore embodiments.

FIG. 2A shows an example of handling a suspicious login 202 with respectto a select user such as, for example, a corporate officer of anorganization. FIG. 2A depicts an example of a single action policyrelating to a predefined rule 139 (FIG. 1 ). An organization may wish toprotect select users from security breaches by implementing a rule 139that monitors suspicious logins. This can mitigate damage if a selectuser’s account is compromised.

As shown in FIG. 2A a suspicious login 202 may occur. The suspiciouslogin may be determined by evaluating whether a particular IP addressassociated with a login attempt is outside a range or is otherwisewhitelisted/blacklisted, whether the login attempt occurs at ananomalous time (e.g., 2AM), whether the login time is inconsistent orlogically impossible with the select user’s schedule (e.g., loginattempt during a select user’s travel), or any combination of suchfactors. Upon detecting a suspicious login 202, the managementapplication 121, determines whether the suspicious login 202 applies toa select user 205. If not, the management application 121 continuesmonitoring. If so, the management application 121 takes a predefinedaction such as, for example, suspending the select user’s account 207such one or more user accounts 112 (FIG. 1 ) of software services 103(FIG. 1 ) associated with the select user.

FIG. 28 shows another example of a single action policy. In FIG. 28 ,the management application 121 monitors whether a user connects to anuntrusted VPN 208. This type of action my increase the risk of asecurity breach by providing a lack of visibility into a user activity211. Upon detecting an untrusted connection, the management application121 may take action, in the manner described above with respect to FIG.2A and/or it may send an alert 154 (FIG. 1 ) to a predeterminedrecipient such as an IT manager or network administrator.

FIG. 2C shows an example of a multi-action policy created by a pluralityof rules 139. In this example, the management application 121 detectsboth a suspicious login 202 and a processing event 148 (FIG. 1 ) suchas, for example, downloading a particular file type 231. If both rulesare triggered with respect to a predefined time (e.g., both events occurwithin 2 minutes of each other), then the management application 121 maytake action, in the manner described above with respect to FIG. 2Aand/or it may send an alert 154.

FIG. 2D shows another example of a multi-action policy created by aplurality of rules 139. In FIG. 2D, a user may login 214 and thenperform sequence of processing events 148 such as repeatedly downloadinga file 217 /220. If the sequence of processing events 154 take placeover a predefined time 223, then the management application 121 may takeaction, in the manner described above with respect to FIG. 2A and/or itmay send an alert 154.

FIG. 3 depicts an example of how the Management Application 121 of FIG.1 manages an entity 127 (FIG. 1 ) that uses the services 103 (FIG. 1 )provided by a plurality of provider computing systems 101 a-n (FIG. 1 ),according to various embodiments. In the example of FIG. 3 , the firstprovider computing system 101 a is a cloud storage system for allowing auser to upload and download his files so that the files can be accessedremotely and potentially shared with the public. The managementapplication 121 creates and assigns a persistent ID (PID) 133 (FIG. 1 )to the user. In this example, that PID for the managed entity is“bob@c.co.” The user may then perform processing events 148 (FIG. 1 )(e.g., download, upload, edit, etc.) relating to a managed data object109 such as a file. In this case, the user is considered a managedentity. Not shown in FIG. 2A is one or more users with which the managedentity can interact with in the computing environment 100, but whom isnot a managed entity. In this regard, the outside user is an “actor” inthe framework of the present disclosure. In addition or in thealternative, the user may execute a script or use an automated processto initiate processing events 148.

In FIG. 3 , the user also uses a second provider computing system 101 bthat provides a different, second software service 103, which may beheterogeneous in relation to the first (or other) software servicesoperational in cloud computing environment 100. In this example, thesecond software service 103 is a file sharing service such as amessaging or email service. The second software service 103 allows theuser to receive or share documents with different groups or channelssuch as, for example, a “Leadership” group or a “Finance” group.

As the user logs in and uses the various software services 103 providedby different providers, the risk of sharing sensitive documentsincreases. To alleviate the risk, the management application 121 appliesone or more associated rules and/or permissions to monitor activity thatcould lead to data loss.

FIG. 3 shows how a document received from a second provider computingsystem 101 b might be inadvertently shared with the public using a firstprovider computing system 101 a. The management application 121 isconfigured to monitor for such undesired activity. The managementapplication 121 may be configured to monitor activity with respect to arule 139 that prohibits the public sharing of files created by theFinance Group. The management application 121 continuously tracksprocessing event information 151 (FIG. 1 ) relating to the variousprovider computing systems 101 a and 101 b. If processing eventinformation 151 associated with a PID 133 (FIG. 1 ) is subject to aparticular rule 139, the management application 121 may take action,such as by generating an alert 154 (FIG. 1 ) or by modifying or revokinga permission 142. In the example of FIG. 3 , when the user who uses thefirst provider computing system 101 a to publicly share the file, asprohibited by a rule 139, the management application 121 responds bygenerating an alert 154.

FIG. 4 provides an example of the functionality of the managementapplication 121 as an improvement over prior solutions. In FIG. 4 , andmanagement application 121 provides services beyond a single sign-onprovider / identity as a service 404. Item 404 represents the limitedability of providing a single login or portal to multiple heterogeneousapplication services. In addition to that, the management application121, provides a platform that does not only monitor user login or useraccounts, it also monitors how entities are using or otherwisemanipulating managed data objects 109 processed by one or moreheterogeneous software services 103 operational in a computingenvironment 100.

FIG. 5 is a flowchart that provides an example of the operation of themanagement application 121 according to various embodiments. It isunderstood that the flowchart of FIG. 5 provides merely an example ofthe many different types of functional arrangements that may be employedto implement the operation of the portion of the software application asdescribed herein. As an alternative, the flowchart of FIG. 5 may beviewed as depicting an example of elements of a method implemented inthe computing environment 100 (FIG. 1 ) according to one or moreembodiments.

Beginning at 502 the management application 121 monitors for processingevents taking place within the computing environment 100. According tosome embodiments, the management application 121 receives APIinformation from various provider computing systems 101 a-n (FIG. 1 ).The management application 121 monitors for SaaS activity taken byvarious users (e.g., managed entities and third-party actors) who useSaaS accounts associated with the computing environment of a particularorganization. When processing event information 151 (FIG. 1 ) isreceived 502, the management application 121, parses the processingevent information, which may include extracting information from an APIgenerated by software service 103 executing in a provider computingsystem 101.

At 505, the management application 121 identifies a managed data object109 (FIG. 1 ) associated with the processing event information 151. Forexample the processing event information 151 may indicate that “file x”is made available via a public URL. In this case, “file x” is themanaged data object 109 and the event of “sharing via a link” is aprocessing event 148 (FIG. 1 ) triggered by an actor associated with aclient environment 145 (FIG. 1 ). The management application 121determines whether the managed data object 109 is associated with a PID133. The management application 121 cross-references a database 124(FIG. 1 ) to determine if a PID for the managed data object 109 exists.If not, then, at 508, the management application 121 generates a PID forthe managed data object and stores it in the database 124 for futureuse. If a PID exists, then, at 511, the management application 121obtains the PID associated with the processing event 148.

At 515, the management application 121 compares the processing event 148with a permission 142 (FIG. 1 ) or rule 139 (FIG. 1 ). For example, apermission 142 or rule 139 may relate to what processing events 148should or should not be taken with respect to what managed data objects109. To identify a managed data object 109, the management application121 uses a PID. In some embodiments, the management application 121 mayalso use an entity ID (130) to track certain entities 127 (FIG. 1 ) inrelation to permission 142 or rule 139, However, unmanaged entities suchas, for example, third party actors, would not have corresponding entityIDs.

At 517, the management application 121 determines whether the processingevent is in compliance 517. Here, the management application 121 checkswhether a permission 142 or rule 139 is violated based on the manageddata object 109 and/or the entity 127 who triggered the processing event148. At 520, the management application 121 generates compliance data orrecord 136 (FIG. 1 ). This may involve updating a record ofnon-compliance that reflects each time a permission 142 or rule 139 isviolated. According to some embodiments, the management application 121generates data or an alert 154 (FIG. 1 ) reflecting the record ofnon-compliance,

At 523, the management application 121 creates an information setregarding one or more processing events. For example, the managementapplication 121 may generate a data graph or report that providescompliance data on a periodic basis. The management application 121 mayprovide a real-time stream of the processing event information so that amanager/administrator can monitor the activity of the client environment145.

At 526, the management application 121 continues to monitor forprocessing events 148 unless the application is terminated.

FIG. 6 shows a schematic block diagram of the management platform 118according to an embodiment of the present disclosure. The platform 118includes one or more computing devices 600. Each computing device 600includes at least one processor circuit, for example, having a processor603 and a memory 606, both of which are coupled to a local interface 609or bus. To this end, each computing device 600 may comprise, forexample, at least one server computer or like device. The localinterface 609 may comprise, for example, a data bus with an accompanyingaddress/control bus or other bus structure as can be appreciated.

Stored in the memory 606 are both data and several components that areexecutable by the processor 603. In particular, stored in the memory 606and executable by the processor 603 is the management application 121.Also stored in the memory 606 may be a database 103 and other data. Inaddition, an operating system may be stored in the memory 606 andexecutable by the processor 603.

It is understood that there may be other applications that are stored inthe memory 606 and are executable by the processor 603 as can beappreciated. Where any component discussed herein is implemented in theform of software, any one of a number of programming languages may beemployed such as, for example, C, C++, C#, Objective C, Java®,JavaScript®, Perl, PHP, Visual Basic®, Python®, Ruby, Flash®. or otherprogramming languages.

Several software components are stored in the memory 606 and areexecutable by the processor 603. In this respect, the term “executable”means a program file that is in a form that can ultimately be run by theprocessor 603. Examples of executable programs may be, for example, acompiled program that can be translated into machine code in a formatthat can be loaded into a random access portion of the memory 606 andrun by the processor 603, source code that may be expressed in properformat such as object code that is capable of being loaded into a randomaccess portion of the memory 606 and executed by the processor 603, orsource code that may be interpreted by another executable program togenerate instructions in a random access portion of the memory 606 to beexecuted by the processor 603, etc. An executable program may be storedin any portion or component of the memory 606 including, for example,random access memory (RAM), read-only memory (ROM), hard drive,solid-state drive, USB flash drive, memory card, optical disc such ascompact disc (CD) or digital versatile disc (DVD), floppy disk, magnetictape, or other memory components.

The memory 606 is defined herein as including both volatile andnonvolatile memory and data storage components. Volatile components arethose that do not retain data values upon loss of power. Nonvolatilecomponents are those that retain data upon a loss of power. Thus, thememory 606 may comprise, for example, random access memory (RAM),read-only memory (ROM), hard disk drives, solid-state drives, USB flashdrives, memory cards accessed via a memory card reader, floppy disksaccessed via an associated floppy disk drive, optical discs accessed viaan optical disc drive, magnetic tapes accessed via an appropriate tapedrive, and/or other memory components, or a combination of any two ormore of these memory components. In addition, the RAM may comprise, forexample, static random access memory (SRAM), dynamic random accessmemory (DRAM), or magnetic random access memory (MRAM) and other suchdevices. The ROM may comprise, for example, a programmable read-onlymemory (PROM), an erasable programmable read-only memory (EPROM), anelectrically erasable programmable read-only memory (EEPROM), or otherlike memory device.

Also, the processor 603 may represent multiple processors 603 and/ormultiple processor cores and the memory 606 may represent multiplememories 606 that operate in parallel processing circuits, respectively.In such a case, the local interface 609 may be an appropriate networkthat facilitates communication between any two of the multipleprocessors 603, between any processor 603 and any of the memories 606,or between any two of the memories 606, etc. The local interface 609 maycomprise additional systems designed to coordinate this communication,including, for example, performing load balancing. The processor 603 maybe of electrical or of some other available construction.

Although the management application 121 described herein may be embodiedin software or code executed by general purpose hardware as discussedabove, as an alternative the same may also be embodied in dedicatedhardware or a combination of software/general purpose hardware anddedicated hardware. If embodied in dedicated hardware, each can beimplemented as a circuit or state machine that employs any one of or acombination of a number of technologies. These technologies may include,but are not limited to, discrete logic circuits having logic gates forimplementing various logic functions upon an application of one or moredata signals, application specific integrated circuits (ASICs) havingappropriate logic gates, field-programmable gate arrays (FPGAs), orother components, etc. Such technologies are generally well known bythose skilled in the art and, consequently, are not described in detailherein.

FIG. 7 shows an example of managing data integration in the computingenvironment 100, according to various embodiments of the presentdisclosure. As described above with respect to FIG. 1 , one or moreprovider computing systems 101 may provide services that involveprocessing a managed data object 109. FIG. 7 shows how managed dataobjects 109 are tracked as they are processed by a provider computingsystem 101. By processing a managed data object 109, different versionsof that managed data object 109 may be created. Data integration refersto reconciling these different version using, for example, using an ETLprocedure.

FIG. 7 shows examples of three ETL processes for tracking managed dataobjects 109 that may be used alone or in combination: monitoring pushnotifications 703, performing a full synchronization 706, and performinga delta synchronization 709. A management platform 118 may monitor pushnotifications 703 to determined how a provider computing system 101 hasmodified a particular managed data object 109. For example, a providercomputing system 101 may generate a notification each time it processesa managed data object 109. These notifications may be obtained by themanagement platform 118 using an API for receiving the notification. Thenotification is thus, “pushed” to the management platform 118 to allowit to track the managed data object 109.

In addition or in the alternative, a full sync 706 may be performed onthe managed data object 109. In this case, the management platform 118obtains a history of the process events that were performed on a manageddata object 109. Then it performs those processing events on the manageddata object 109 to generate a new managed data object 109 that capturesthe history of process events performed on the managed data object 109over time.

In addition or in the alternative, the management platform 118 performsa delta sync 709, which, in real-time processes the managed data object109 to mirror the processing performed by the provider computing system101.

Regardless of the three ETL processes described above, the variousversions of the managed data object 109 are reconciled into a commonintegrated managed data object. In this respect, a PID associated withthe integrated managed data object applies to the various versions of aprocessed data object 109.

Also shown in FIG. 7 is an enrichment process 712. The enrichmentprocess 712 appends data received from the provider computing system 101u with non-API related data stored by the management platform 118 toprovide additional context to the notifications received from theprovider computing system 101. In addition, a state processor 715 isused to track the various versions of a managed data object 109 as it isbeing processed by a provider computing system 101. A data graph 718stored in a database, such as the database 124 of the managementplatform 118 may be generated to track the various versions of a manageddata object 109.

The flowchart of FIG. 5 shows the functionality and operation of animplementation of the management application 121. If embodied insoftware, each box may represent a module, segment, or portion of codethat comprises program instructions to implement the specified logicalfunction(s). The program instructions may be embodied in the form ofsource code that comprises human-readable statements written in aprogramming language or machine code that comprises numericalinstructions recognizable by a suitable execution system such as aprocessor 603 in a computer system or other system. The machine code maybe converted from the source code, etc. If embodied in hardware, eachblock may represent a circuit or a number of interconnected circuits toimplement the specified logical function(s).

Although the flowchart of FIG. 5 shows a specific order of execution, itis understood that the order of execution may differ from that which isdepicted. For example, the order of execution of two or more boxes maybe scrambled relative to the order shown. Also, two or more boxes shownin succession in FIG. 5 may be executed concurrently or with partialconcurrence. Further, in some embodiments, one or more of the boxesshown in FIG. 5 may be skipped or omitted. In addition, any number ofcounters, state variables, warning semaphores, or messages might beadded to the logical flow described herein, for purposes of enhancedutility, accounting, performance measurement. or providingtroubleshooting aids, etc. It is understood that all such variations arewithin the scope of the present disclosure.

The management application 121 may also comprises software or code canbe embodied in any non-transitory computer-readable medium for use by orin connection with an instruction execution system such as, for example,a processor 603 in a computer system or other system. In this sense, thelogic may comprise, for example, statements including instructions anddeclarations that can be fetched from the computer-readable medium andexecuted by the instruction execution system. In the context of thepresent disclosure, a “computer-readable medium” can be any medium thatcan contain, store, or maintain the logic or application describedherein for use by or in connection with the instruction executionsystem.

The computer-readable medium can comprise any one of many physical mediasuch as, for example, magnetic, optical, or semiconductor media. Morespecific examples of a suitable computer-readable medium would include,but are not limited to, magnetic tapes, magnetic floppy diskettes,magnetic hard drives, memory cards, solid-state drives, USB flashdrives, or optical discs. Also, the computer-readable medium may be arandom access memory (RAM) including, for example, static random accessmemory (SRAM) and dynamic random access memory (DRAM), or magneticrandom access memory (MRAM). In addition, the computer-readable mediummay be a read-only memory (ROM), a programmable read-only memory (PROM),an erasable programmable read-only memory (EPROM), an electricallyerasable programmable read-only memory (EEPROM), or other type of memorydevice.

Further, any logic or application described herein, including themanagement application 121, may be implemented and structured in avariety of ways. For example, one or more applications described may beimplemented as modules or components of a single application. Further,one or more applications described herein may be executed in shared orseparate computing devices or a combination thereof. For example, thesoftware application described herein may execute in the same computingdevice 600, or in multiple computing devices in the same computingsystem 603. Additionally, it is understood that terms such as“application,” “service,” “system,” “engine,” “module,” and so on may beinterchangeable and are not intended to be limiting.

Disjunctive language such as the phrase “at !east one of X, Y, or Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to present that an item, term, etc., may beeither X, Y, or Z, or any combination thereof (e.g., X, Y, and/orZ).Thus, such disjunctive language is not generally intended to, andshould not, imply that certain embodiments require at least one of X, atleast one of Y, or at least one of z to each be present.

It should be emphasized that the above-described embodiments of thepresent disclosure are merely possible examples of implementations setforth for a clear understanding of the principles of the disclosure.Many variations and modifications may be made to the above-describedembodiment(s) without departing substantially from the spirit andprinciples of the disclosure. All such modifications and variations areintended to be included herein within the scope of this disclosure andprotected by the following claims.

1. A method of managing Saas applications operational in a cloudcomputing environment comprising: a. providing, by a computing system, acloud computing environment operational with each of: i. a plurality ofSaas applications each having a Saas application type; and ii. aplurality of managed entities each having an entity identification andone or more entity types; b. defining, by the computing system or anadministrator, one or more rules for: i. processing operationsassociated with each of the plurality of SaaS applications; ii.processing operations associated with each of the plurality of managedentities; and iii. processing operations associated with one or moremanaged entity types; c. identifying, by the computing system, a firstSaas application operational in the cloud computing environment, whereinthe identification is in response to information received aboutprocessing of the first Saas application in the cloud computingenvironment, and wherein the processing is associated with one or moreof the managed entities; d. determining, by the computing system,whether the first Saas application is, independently, associated with apersistent identifier (PID) and, if the first Saas application is notassociated with a PID, assigning a PID to the first Saas application,thereby providing a PID-associated SaaS application; e. identifying, bythe computing system each of: i. a Saas application type for thePID-associated Saas application; ii. a managed entity identification foreach managed entity associated with the processing of the PID-associatedSaas application; and iii. a managed entity type for each managed entityassociated with the processing of the PID associated Saas application;f. determining, by the computing system, whether the processing of thePID-associated Saas application is out of compliance with one or morerules associated with the processing of Saas applications in the cloudcomputing environment, wherein the one or more rules are defined foreach of: i. Saas application type; ii. identity of a managed entityassociated with the processing of the PID-associated Saas application;and iii. managed entity type associated ,vith the processing of thePID-associated Saas application; and g. generating, by the computingsystem, information about whether the processing of the PID-associatedSaas application is out of compliance with the one or more rules.